justinsb
commented
1 year ago I think this could be a great feature. I was imagining that normally when the "parent" object is cluster-scoped, that the namespace-scoped objects would be in well-known namespaces (i.e. you can't really have multiple instances). But when this isn't the case, I can see WithNamespace being useful.
I think WithNamespace could be a "normal" ObjectTransform, so I think you can write it in your controller and then we can promote it into the shared library if/when other people need it (or just to encourage them to use it because we think it's a good idea)?
Are there things you need in k-d-p or from k-d-p to enable you to write this (e.g. some utility functions)? If so I think that could be a great place to start, and then we can look at the end result and add that?
yuwenma
k8s-triage-robot
k8s-ci-robot
Problems
In my case, my deployment manifests have both cluster scoped resources (e.g.
CustomResourceDefinition,ClusterRoleBinding) and namespace scoped resources(e.g.Deployment,Service). I want to assign a namespace value to the namespace scoped resources. I also want thedeclarativeObjectto be theownerRefof both kinds, so that I can have the deployment manifests be easily cleaned up by just deleting thedeclarativeObject.Available features
Current k-d-p provides 3 handy features:
declarativeObjectis namespace scoped, its value can be used to modify any namespace scoped deployment manifests which does not have the namespace assigned.WithPreserveNamespace.declarativeObjectto be the owner of the deployment manifests, which is very easy for resource clean up. This can be done viadeclarative.WithOwner(declarative.SourceAsOwner). If thedeclarativeObjectis namespace scoped, the cluster scoped deployment manifests will be skipped and won't have a ownerRef. thedeclarativeObjectis cluster scoped, all manifests will have it as theownerRef.My current solutions
Right now, I have two options but neither are handy enough:
Option 1:
Set the
declarativeObjectas namespace scoped, this will auto-assign the namespace to deployment manifests. It has two problems:declarativeObjectobject and cannot rely on my k-d-p operator to guarantee the existence of the namespace.ownerRefif cluster resources.Option 2:
The
declarativeObjectis cluster scoped. It can be theownerRefof all manifests and I can add the namespace existence logic in my k-d-p operator. But I have to implement my own declarative methods to update the namespace.Proposals
Add a new declarative method which does not rely on the
declarativeObjectbut can assign given namespace to the deployment manifests (it's different than skipping the namespace as whatWithPreserveNamespacedoes, but assigning default namespace). Even better, if the namespace object does not exist in the cluster, I want it to be created by request.New declarative method
WithNamespace(namespace string, createIfNotExist bool)This method assigns namespace
namespaceto any namespace scoped deployment manifests, only if their current namespace is empty (basically the same behavior of currentsetNamespacesbut using a dedicated namespace value).namespaceis the dedicated namespace value,createIfNotExistguarantees the existence of the namespace object before applying any other resources.Please share your thoughts!
I think the use case I described can be very common for users who need k-d-p. And I'm just proposing a simple solution that is good enough for my use case. I think the behavior of
WithNamespacecan also be extended to update all the namespace-scoped deployment manifests rather than merely the unassigned ones. But I don't have a strong opinion on this.Besides updating the
metadata.namespace, we can also extend thesetNamespaceto updatespec/conversion/webhook/clientConfig/service/namespaceinCustomResourceDefinition,spec/service/namespaceinAPIService, etc.