-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecation of kustomize cfg
and kustomize fn
alpha commands
#3953
Comments
I thought the experimental cfg command group had already been removed, but since it hasn't... At least the tree command is useful, from what I've heard, but there's also the kubectl plugin: The readonly commands could make a reasonable "view", "browse", or "scan" command group parallel with edit and build, though. Setters (set) would fit as a transformer. The replacement transformer is powerful, but is verbose and requires centrally identifying targets. Setters would work more like the other transformers in that targets wouldn't need to be specified in kustomization.yaml. A target-identification transformer could also be added later, if necessary, but restricting to targets already specified in base resources is pretty useful already. I think of setters as an ad hoc transformer for cases where a dedicated transformer (like images, replicas) hasn't been built yet. A command to set setter values in kustomization.yaml would fit under edit. I agree regarding removing the mutation commands. |
I don't think it makes sense to keep the Krmfile. |
+1 to keeping the readonly commands and removing the others. There are KRM functions for creating and applying setters that kustomize could theoretically reuse with |
I think I disagree that setters should be re-implemented as a transformer. See kptdev/kpt#2369 (comment) It seems much more reasonable to have a hard distinction between in-place and out-of-place hydration. In combination with something like #3980 and a declarative function execution pipeline in kustomize I see no reason why setters would ever need to be performed out-of-place. If setters are applied in a transformer I foresee similar issues to #4031 where changes to a resource's GVKNN are not tracked appropriately. |
@marshall007 WDYT about setters as a KRM function? |
kustomize performs out-of-place transformation/hydration, driven by a declarative specification (https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2377-Kustomize#capabilities). That's its model. Out-of-place transformations are especially useful for variant generation. In fitting with that model and usage, it should be possible to generate multiple variants from the same base. As seen with vars (#2052) and replacements (#1631), there is demand for a substitution mechanism that works with the out-of-place model. That setters used an in-place model was an accident of implementation while exploring (#1113 (comment)) alternatives to inline substitution (https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/declarative-application-management.md#what-about-parameterization). More generally, the in-place transformations provided an experimental method of exercising the new yaml transformation libraries (#1749), but lacked a holistic design for how they would fit with existing out-of-place functionality. Hence this issue. |
@natasha41575 thanks for pointing out those KRM functions. Couldn't the "apply-setters" function be invoked declaratively as a KRM-style transformer today then? If so, the question is whether we need to bring that functionality in-tree vs. promote the use of that extensions transformer to those interested. Personally I like the idea of it remaining a extensions feature rather than bringing the additional concept (and need to explain it and contrast it with other features) into Kustomize core. Re: the read-only commands, @bgrant0607 makes a good point about kubectl plugins. It seems to me none of those really have to do with Kustomize so much as with resource inspection in general. This makes me lean towards removing them as well, and possibly publishing the code as kubectl (krew) plugins from the experimental repo, if there's interest (and maybe even move some to kubectl itself some day if they take off?). That republishing could be an interesting standalone project for someone. |
@natasha41575 I think the UX of the new
As an author of generic CI/GitOps tooling there is no longer an easy way to know which mechanism should be used by introspecting a given package. It wasn't necessarily ideal, but it used to be that you could check for the presence of a As a package author, I used to be able to provide both a I am a fan of how I had already typed all that out before @bgrant0607 's response. So it sounds like in addition to the cfg command group we should also be looking to deprecate |
I agree with @KnVerey that the core introspection command functionality doesn't really belong in kustomize either. It never really made sense to me that the output didn't reflect any out-of-place hydration defined in the kustomization(s). There would still be value in a kustomize-aware wrapper around the core functionality, but the core implementation belongs elsewhere for sure. |
🤔 I'm open to this. With that deprecation, it looks like we'd be left with commands that interact with Kustomization, which makes a lot of sense to me. That said, I can see how |
Yes, the imperative fn commands are also worthy of scrutiny. The commands should have been alpha. KEPs for plugins and functions: |
I just tested it out with the following:
and
and received the error My hunch is that it is because kustomize doesn't preserve comments and some debugging shows that the setter comments are lost by the time the function is executed on the yaml. If we want to support setters as a transformer, we might need to look into comment preservation during unmarshaling. The same issue happens when using It does work with |
/retitle Deprecation of We've merged the deprecation of most of the cfg alpha commands in #4048 . I'm thinking we don't need to hold off deprecating alpha commands that aren't integrated with Kustomization just because we may in the future implement similar functionality that IS integrated. @natasha41575 wdyt about deprecating the readonly commands as well, to ultimately get rid of the whole Does anyone object to also deprecating Re: comment preservation, it sounds like we must not be using kyaml at our entry point. That would certainly be worth a try, but I suspect it won't be smooth sailing. E.g. if that effectively changes us over to a yaml 1.2 unmarshaler, booleans will get treated differently. |
kustomize cfg
alpha commandskustomize cfg
and kustomize fn
alpha commands
Between deprecation and enhancing them to inflate a kustomization, I slightly prefer the latter but I don't have a strong opinion. Would we try to find another home for the commands or just get rid of them altogether? IMO they're kind of handy to have around and are easy to maintain.
I don't see the value of the others, but I do see value in |
I'm ok with that, and I've opened an issue about it here: #4090
Ok, let's keep |
/assign |
We have deprecated the |
Are there any tools around to format kustomize files/patches? |
Kustomize currently has a
kustomize cfg
subcommand that contains a variety of alpha yaml manipulation tools:As part of our efforts to stabilize Kustomize APIs, we should decide what to do with these. They're loosely related to Kustomize in that keeping your configuration expressed in the canonical APIs (template-free) enables you to use such tools on your raw config. But at the same time, these tools aren't specific to Kustomize or part of recommended Kustomize workflows AFAIK.
Proposal:
The above is a starting point for discussion rather than a strong opinion. Other options that come to mind: publish current
cfg
as a separate binary (kyaml?), or move to cli-experimental repo./triage under-consideration
/area cli
/kind deprecation
The text was updated successfully, but these errors were encountered: