-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Add cluster spec to node user data so component config changes are detected #3120
Add cluster spec to node user data so component config changes are detected #3120
Conversation
Hi @KashifSaadat. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with I understand the commands that are listed here. 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. I understand the commands that are listed here. |
5a22358
to
c497d4d
Compare
/assign @zmerlynn |
c497d4d
to
089aa6b
Compare
6c3e5a4
to
c7c41c1
Compare
So I was a little confused, but then I realized that we never merged #2167 I don't think this needs to be optional; it should be the default behaviour. In #2167 I just hashed "everything", and I like how you only hash the relevant data. My thought was to start with everything and then start excluding things we knew to be irrelevant. I'm not sure how we want to reconcile the two approaches. We could merge #2167 and then we can take your code to be more selective in what we fingerprint. Or we could remove the API fields from this PR (if you agree) and I think this PR will then be simpler. I'll rebase #2167 - feel free to have a look and review. If you like it you can even comment with LGTM, even if the bots don't technically count it, I always encourage people to review & LGTM - at the end of the day there are people making the final decisions :-) If you'd rather follow this PR, that's great also. My instinct is that we don't need the API fields, but I am open to an explanation of why they are needed :-) |
Also I just sent #3139 which exposes the name of the tempfile used during the CF tests, which can be a time-saver :-) |
Hey @justinsb, thank you for the feedback and the call! :) I'll get the PR updated and re-push following your comments (full cluster spec not hashed, drop API fields). |
4cedca3
to
03e1a71
Compare
Updated the PR following comments, let me know what you think! :) |
pkg/model/bootstrapscript.go
Outdated
@@ -34,7 +37,7 @@ type BootstrapScript struct { | |||
NodeUpConfigBuilder func(ig *kops.InstanceGroup) (*nodeup.Config, error) | |||
} | |||
|
|||
func (b *BootstrapScript) ResourceNodeUp(ig *kops.InstanceGroup) (*fi.ResourceHolder, error) { | |||
func (b *BootstrapScript) ResourceNodeUp(ig *kops.InstanceGroup, cs *kops.ClusterSpec) (*fi.ResourceHolder, error) { |
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.
could we have a comment on the exported func
6b4cccf
to
c4b72db
Compare
Hi @justinsb, updated the PR following comments & test failures:
|
@KashifSaadat PR needs rebase |
c4b72db
to
56d0748
Compare
6d9b1fd
to
f4b7909
Compare
so component config changes are detected and causes nodes to be updated
f4b7909
to
e0461b9
Compare
/ok-to-test /lgtm Looks great - solves a real problem, and positions us very well to actually pass the data to nodeup via this mechanism (assuming that we can squeeze under the size limit!) |
spec["masterKubelet"] = cs.MasterKubelet | ||
} | ||
|
||
content, err := yaml.Marshal(spec) |
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 wonder if we should actually use the typed version i.e. take the spec & zero out the bits we don't want, and then use the existing API marshalling. Then we could use this as the versioned API between kops & nodeup...
But I'm getting ahead of myself - this 👍
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.
Yeah that's a good option. When I was using the existing API marshalling I was doing conversion from Spec -> JSON -> YAML, which looked a bit messy. Was a bit unsure on the most ideal approach.
{{ ClusterSpec }} | ||
__EOF_CLUSTER_SPEC | ||
|
||
cat > ig_spec.yaml << __EOF_IG_SPEC |
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 like where this is going :-)
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: KashifSaadat, justinsb The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
/test all [submit-queue is verifying that this PR is safe to merge] |
Automatic merge from submit-queue |
Automatic merge from submit-queue Add hooks to bootstrapscript output Ping @gambol99 Related to: - #3120 - #3063 Cluster Hooks are now added in their entirety to the nodeup user data scripts, dependant on whether the instance group roles match. This could increase the size of the user-data files significantly (getting closer to the 16KB mark) depending on users' hooks content. I considered hashing and fingerprinting the cluster hooks, but following discussions in #3120 thought we should keep the full output instead.
Related to #3076
Some cluster changes such as component config modifications are not picked up when performing updates (nodes are not marked as
NEEDUPDATE
). This change introduces the ability to:(enableClusterSpecInUserData: true
)Encode the cluster spec string before placing within the user data file (enableClusterSpecInUserData: true
)The above flags default to false so shouldn't cause any changes to existing clusters.Following feedback I've removed the optional API flags, so component config is included by default within the user data. This WILL cause all nodes to have a required update to their bootstrap scripts.