Automatically create user-data secret for each MCP #319
Comments
|
Sounds good to me. |
|
SGTM as well but I don't think this prevents #368 from landing and the plan around managing this user data (as well as bootimages) from the MCO isn't fully hashed out either, see openshift/machine-config-operator#683 (comment) (that's yet another direction...). So, I think this would be valuable as well and we can work on something for the next release (#368 is specific for the v3 migration which is tricky per-se and we want to avoid to pull in other changes like this could be..) |
|
/cc @enxebre @cgwalters |
|
This is openshift/machine-config-operator#1619 right? |
|
I think we should do it but let's get #368 first, doesn't need to happen at the same time. |
|
this sounds reasonable to me as well |
|
Would we agree this is more like a bug/shortcoming we have in MCO? why do we need an enhancement? it sounds like a straightforward fix we can do in the MCO anyway (as we sync the original pools and we can add the userdata creation there as well) |
|
@runcom well, it's one of those things that touches multiple areas. The machine-api needs to have the user-data secret, MCO needs to create it. Whether or not this amounts to the level of an 'enhancement' IDK. I filed it in this repo because it's a cross-component issue. I didn't write a full enhancement because that seems unnecessary. |
|
@michaelgugino we've done this here https://github.com/openshift/machine-config-operator/pull/1792/files#diff-fa45321336db7ad1cedc28bf643a4f97R380-R404 - now any pool is getting its stub ignition config |
|
@runcom looks good. Anything cleaning these secrets up? I think it's probably okay to leave them there for the most part. |
nothing today but we can add something going forward - we don't have anything cleaning unused MCs yet so it should be safe as we're going to rerender the secrets as well in case something changes |
@runcom yeah, I think cleaning up MCs based on 'unused' is tricky. It might be a config I only use every so often for a particular type of workload, so it might be perfectly valid to have a MC that goes unused for an extended period of time. As far as deleting the user-data, I'm fine with it not being deleted automatically. I think we could potentially set an owner-ref (does that work cross namespace?) on the user-data pointing to the relevant MCP and cleanup will happen automatically (again, not required IMO). |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci-robot
added
the
lifecycle/stale
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci-robot
added
lifecycle/rotten
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closing this issue. In response to this:
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. |
|
/reopen |
|
@michaelgugino: Reopened this issue. In response to this:
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. |
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closing this issue. In response to this:
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. |
|
/reopen |
|
@michaelgugino: Reopened this issue. In response to this:
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. |
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closing this issue. In response to this:
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. |
Currently, the installer creates the initial user-data (stub ignition file) that is provided to machines on first boot to configure the host. This ignition stub contains a url that specifies the name of a MachineConfigPool. If a user creates a custom MachineConfigPool, the user must create a new stub ignition file manually, which is quite tedious.
We should automatically generate a new user-data secret for each MachineConfigPool created by the MCO. This would allow users to more easily consume custom MCPs via the machine-api by just specifying the corresponding user-data secret.
The text was updated successfully, but these errors were encountered: