Creating namespaces and pods, in that order, using landscaper

[zmalik]

Hi guys,

We are trying to use landscaper to deploy charts in our kubernetes cluster. And we have got a use case here. I'm posting here so maybe somebody can shed light on it.

We are deploying namespaces and pods using landscape. But when we apply, landscape sends all components to be created to helm. And as helm is trying to apply the state. Sometimes it tries to create a pod which belongs to a namespace that hasn't been created yet.

So what can be possible solutions of this?

1. We can try to apply first namespaces only, and then apply all of the charts(including namespaces). The first time it would work nicely. But second time when we apply namespaces only, it will delete the rest of the pods. And later create them again. Not a desirable cycle.
   One feasible solution to go with this would be providing a flag in landscape, like -disableDeletes
   That would allow disabling DeleteComponent stage in the apply. Meaning that first, we apply namespaces with this flag. Won't delete rest of pods, but also won't delete the namespaces that are supposed to be deleted. But in next step when we apply all of the charts (without disableDeletes flag). The state of the cluster would be correct.

That would be one approach. Letting people disable delete/update/create stages in landscaper using some flag. That would solve our use case also.

2. We have been thinking about an alternative approach. Which would be when we do

landscaper apply files1/ files2/

Make it respect the order, only in create components stage, and in first place send to helm files1 and once finished then send the files2.

That would solve our use case also. But don't know if other users can find a use case to be solved here.

In both cases, we are happy to collaborate and can create the PR, once we have reached a consensus about some possible solution.

Thanks

[ivanilves]

👍

[rollulus]

Hi, just to let you know that this isn't an abandoned project: I'll have a more in depth look later on.

[zmalik]

@rollulus great to know, I just evaluated the implementation of both options. And to keep it going on my side I did the option 1. As option 2 is caused by random order in Go maps. Trying to use a treemap implementation would be way too many changes in the code.

I'm going to open a PR so you can visualize the option 1 better.

[zmalik]

This issue can be mitigated using the disable step feature of landscaper

Closing the issue