Narrow down the usage of InitConfiguration throughout the code base #1084
Labels
kind/cleanup
Categorizes issue or PR as related to cleaning up code, process, or technical debt.
kind/design
Categorizes issue or PR as related to design.
lifecycle/active
Indicates that an issue or PR is actively being worked on by a contributor.
priority/backlog
Higher priority than priority/awaiting-more-evidence.
Milestone
With the push towards
v1beta1
config, a lot of the internal structures got split and narrowed in scope.However, the
InitConfiguration
is still the most widely spread type in the entire kubeadm code base. This was fine with the oldMasterConfiguration
since it was stored as is in a config map, but currently it's inadequate for a number of reasons:kubeadm init
config file structure (in order to pass parameters for the initial init process).kubeadm init
, thus allowing for bugs and even security vulnerabilities to plague the code base (Currently onlyBootstrapTokens
).The initial intent, when
v1alpha3
was began, was that almost all usages ofInitConfiguration
outside ofkubeadm init
code, could be easily replaced withClusterConfiguration
. However, later in the development process of v1.12, it became obvious thatClusterConfiguration
is not sufficient. This is because the structure does not contain any information about API endpoints and node specific options.Thus, we need to define a new primarily runtime only structure, that will have the following fields and allow all kubeadm sub command independent code to operate on it:
/kind design
/kind cleanup
The text was updated successfully, but these errors were encountered: