-
Notifications
You must be signed in to change notification settings - Fork 716
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 UpgradeConfiguration/ResetConfiguration API types #2489
Comments
we discussed with @fabriziopandini during the kubeadm office hours today that we should delay the addition of these new structures until we have a better understanding of nodespecific configuration and the kubeadm roadmap as a whole. |
/cc @wangyysde |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale @neolit123 is the time to pick this up? I saw the KEP is closed with no progress yet. |
we should likely book another kubeadm office hours to discuss this. but if you'd like you can also draft a google doc proposal about it following the kep template on which we can comment. |
sure, I am going to do more investigation on this and make sure I understand the whole pic before sending the google doc. /assgin |
/assign |
sent the doc to the mailing list, paste the link here as well: https://docs.google.com/document/d/1R4zLtgDadNM8_N2VzS0DI2mADcYmkyJ3L7lJVpbyZsA |
@neolit123 pls help to review at your convenience, thanks! :) |
thanks @chendave . i did an initial pass on the doc |
kubeadm currently has some matching configuration formats for its main commands.
join - JoinConfiguration
init - InitConfiguration
upgrade - none
reset - none
we should eventually provide API types for all main commands to avoid flags.
note this was not discussed as part of v1beta3, so it can happen in a future API version.
these are added in v1beta4
upgrade
upgrade does not have a config, forcing users to rely on flags only and forcing us as maintainers to have some flags unique to "upgrade" only.
we should add a scoped UpgradeConfiguration structure that can hold a number of relevant options to upgrade.
--config for upgrade should accept this configuration and not ClusterConfiguration | InitConfiguration...
maybe CC too:
#1681
UpgradeConfiguration
API types kubernetes#114062reset
this makes sense for consistency with respect to
skipPhases
. one other option is--force
.overall the structure for reset would be very minimal since it does not have a lot of options.
ResetConfiguration
API types kubernetes#113583The text was updated successfully, but these errors were encountered: