-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Resource options as annotations #4061
Resource options as annotations #4061
Conversation
@natasha41575: This PR has multiple commits, and the default merge method is: merge. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: natasha41575 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
plugin/someteam.example.com/v1/bashedconfigmap/BashedConfigMap_test.go
Outdated
Show resolved
Hide resolved
/test kustomize-presubmit-master |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed that at least two of these options already have corresponding annotations, for transformers to use:
kustomize/api/internal/plugins/utils/utils.go
Lines 25 to 26 in 7fae7d1
HashAnnotation = "kustomize.config.k8s.io/needs-hash" | |
BehaviorAnnotation = "kustomize.config.k8s.io/behavior" |
Should we be migrating the options individually?
plugin/someteam.example.com/v1/bashedconfigmap/BashedConfigMap_test.go
Outdated
Show resolved
Hide resolved
00d2b86
to
0ad0d02
Compare
Regarding these annotations: kustomize/api/internal/plugins/utils/utils.go Lines 25 to 26 in 7fae7d1
I didn't realize those annotations were there, but they seem to be for users to be able to set the behavior/hash suffix option for their plugins. The ones I have added are for kustomize to process and are replacing private variables, so arguably shouldn't be set or modified by users or anything else. In the spirit of aligning with #3995, WDYT about keeping the existing annotations, and having the new annotation be Arguably the other build annotations should also have the |
sgtm
I agree |
3741652
to
a7f1ad0
Compare
i'm reading through this, thanks for taking this on |
api/resource/resource.go
Outdated
// SetOptions updates the generator options for the resource. | ||
func (r *Resource) SetOptions(o *types.GenArgs) { | ||
r.options = o | ||
if o.IsNilOrEmpty() { | ||
return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this clear the annotation, e.g. is it possible it was present before and has been cleared during the lifetime of the Resource?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm now clearing it when o == nil
, but if I do so when o.IsNilOrEmpty
, some generated resources don't get the hashes they need.
There's something very subtly different about o == nil
vs o.args == nil
, and the distinction is important so that most resources aren't hashed by default, but generated resources are hashed by default. But I don't fully understand the code and it confuses me.
In the case that o != nil
and o.args == nil
I tried
- clearing the annotation - which makes some generated resources not get the hashes they need
- setting the annotation to
{}
- which makes some nongenerated resources get hashes they shouldn't have. With some trial and error the only way that I've been able to make all the tests pass is to do nothing.
The only time options must be cleared is during merging I think, when a generated resource is merging with an existing resource. TestIssue3393
covers this case and the behavior is now corrected to what it was before.
@@ -101,7 +101,6 @@ func (r *Resource) CopyMergeMetaDataFieldsFrom(other *Resource) error { | |||
} | |||
|
|||
func (r *Resource) copyKustomizeSpecificFields(other *Resource) { | |||
r.options = other.options |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is subtly different than the previous behavior. Before, when performing a merge, the “other” object’s options completely override those of the receiver. But annotations are merged. So if the receiver has options and the “other” doesn’t, before that would presumably clear the options and after the options would be retained. That might be what's happening in our mysterious ConfigMap test case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a line - it's now r.SetOptions(other.getOptions)
which seemed to fix the ConfigMap case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! Should we move it up to CopyMergeMetaDataFieldsFrom
field though? It's not a Kustomize-specific field anymore.
Looking at that code, I also wonder if we could avoid resetting the annotations repeatedly by making a version of mergeStringMaps
that is build-annotation-aware.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at that code, I also wonder if we could avoid resetting the annotations repeatedly by making a version of mergeStringMaps that is build-annotation-aware
That's a good idea, I added one called mergeStringMapsWithBuildAnnotations
, ptal!
aedc5c4
to
c51710b
Compare
api/resource/resource.go
Outdated
delete(annotations, utils.BuildAnnotationsRefBy) | ||
r.SetAnnotations(annotations) | ||
} | ||
for _, id := range ids { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we are repeatedly getting, mutating and setting the annotations here. Could we instead make a new helper like r.replaceCsvAnnotation(name, values...)
to make this more straightforward/efficient?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mergeStringMapsWithBuildAnnotations
makes r.setRefBy
unnecessary so I removed it
@@ -101,7 +101,6 @@ func (r *Resource) CopyMergeMetaDataFieldsFrom(other *Resource) error { | |||
} | |||
|
|||
func (r *Resource) copyKustomizeSpecificFields(other *Resource) { | |||
r.options = other.options |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! Should we move it up to CopyMergeMetaDataFieldsFrom
field though? It's not a Kustomize-specific field anymore.
Looking at that code, I also wonder if we could avoid resetting the annotations repeatedly by making a version of mergeStringMaps
that is build-annotation-aware.
api/internal/utils/makeResIds.go
Outdated
BuildAnnotationsRefBy = konfig.ConfigAnnoDomain + "/refBy" | ||
BuildAnnotationsGenOptions = konfig.InternalConfigAnnoDomain + "/generatorOptions" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just change the definition of konfig.ConfigAnnoDomain
to internal.blah.blah
so they all have the same prefix instead of having two? All of these are internal
in the sense that they only appear in the kustomize build pipeline and aren't emitted out the end or saved anywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
The only exception to that is config.kubernetes.io/local-config
which can be read and used by functions so I just updated it to not use ConfigAnnoDomain
api/types/genargs.go
Outdated
} | ||
|
||
// GetArgs returns a copy of the underlying GeneratorArgs | ||
func (g *GenArgs) GetArgs() GeneratorArgs { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GenArgs
exposes only
ShouldAddHashSuffixToName
Behavior
(create, replace, merge)
These fields are special relative to other fields in GeneratorArgs
because they must be consulted when overlays are processed and during the final name-fixing pass. The remaining GeneratorArgs fields are used only at resource creation time and are disposable after that.
To make the special fields available up the stack, it was clearest at the time to wrap GeneratorArgs in an immutable facade that exposed only those fields. Alternatively, the two fields could have been copied out into two new member fields of Resource. The thought was maybe more generator metadata might need to be exposed, so they were kept together.
Providing a GetArgs
method which exposes the backing defeats this information hiding and opens the door to weirdness, so lets not. Since it's exposed only to marshal yaml, the thing to do here would be to offer a AsYaml
method here - however....
However, the new pattern of using attributes to store resource metadata, and the fact that in several years of use we've not had to add more generator args, makes this GenArgs
design moot.
Suggest :
- No more GenArgs.
- BuildAnnotationsGenOptions becomes two constants - for ShouldAddHashSuffixToName and Behavior for two new annotation fields
- two new Resource setter/getter pairs that read/write these fields (in the spirit of
AllowNameChange
,NameChangeAllowed
etc) - Where one would call
SetOptions
, one calls two setters, and likewise forgetOptions
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, if you want to cut it off here, submit this, and continue in another PR (dedicated to deleting GenArgs) that's fine.
in that case just drop GetArgs and do AsYaml instead (don't break the hiding)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, if you want to cut it off here, submit this, and continue in another PR (dedicated to deleting GenArgs) that's fine.
I'd like to do that. This PR is getting pretty big, so I can start working on a followup to drop GenArgs
right after this is merged. For this PR I changed GetArgs
to AsYaml
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the context!
c51710b
to
ea918eb
Compare
/lgtm |
fixes #3975
An e2e test for generator options is at
kustomize/api/krusty/generatoroptions_test.go
Line 48 in 259fcfc
ALLOW_MODULE_SPAN