-
Notifications
You must be signed in to change notification settings - Fork 462
controller: Prefix generated configs with pool type #218
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
controller: Prefix generated configs with pool type #218
Conversation
|
/retest |
ashcrow
left a comment
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 it!
|
/cc @abhinavdahiya |
|
Though I imagine there's some better code to do this type of thing somewhere; e.g. how deployments turn into pods prefixed with a random ID etc. I'm a kube-code novice so pointers appreciated if someone has them. (Also, related to that, is there a reason we use a checksum rather than just a short "unique-enough ID"?) |
using checksums allows MCC to manage generated machine configs without storing that hash somewhere in annotations like deployment does for pods. |
I don't understand this; what does "manage" here mean? As best I can tell nothing e.g. re-hashes a config again to compare it versus something else. It's just about being unique right? |
This way it's easy to see at a glance where a given config came from. Now looks like: ``` $ oc get machineconfig NAME AGE 00-master 6h 00-worker 6h ... master-e92af7e0bdc0591dc11405aeabb57ccd 1m worker-50748faa54f9cc70af13c8686c2c7a28 1m ```
a4a0054 to
58d6e1b
Compare
|
|
OK, understood now. Thanks! One thing I'd note here is this is a "schema change"; it will cause new configs to be generated in existing clusters. I think that's OK because we haven't shipped yet, but now would definitely be the time to think of any other improvements to the naming scheme. |
|
/test e2e-aws |
|
This would be really helpful when looking at lists of machineconfigs, but I'll hold my approval and defer to @abhinavdahiya :) |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: abhinavdahiya, cgwalters The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
6 similar comments
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
Seeing: /test e2e-aws |
|
Masters didn't start/stay running. /test e2e-aws |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
Same failure over here... Right around the same time. I wonder if AWS briefly fell over. /retest |
|
/test e2e-aws It was the same error as @crawford referenced occurring again 😕. |
|
@ashcrow Hopefully, this will be fixed by openshift/installer#882. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/test e2e-aws |
This way it's easy to see at a glance where a given
config came from. Now looks like: