-
Story
-
Resolution: Done
-
Major
-
None
-
None
Description
The WICD binary will be in charge of most on-node operations. WICD's most basic functionality will be the `bootstrap` command. This command is a one-shot operation which directs WICD to ensure that a Node object is created for the VM it is ran on. The Node object is created as a result of the kubelet service running and the appropriate CSRs being approved. WICD therefore has to create the kubelet and all other services required for node object creation The definitions of these services can be found in the service ConfigMap, and can be identified by the bootstrap flag being set.
Engineering Details
For more information refer to the Windows health management epic
The bootstrap command should receive one argument, the services ConfigMap data as an encrypted string.
WICD must validate the following:
- Bootstrap services cannot depend on a non-bootstrap service
- Each service that has the bootstrap flag set as true must have a higher priority than all non-bootstrap services
- There should be no overlap in the priorities of bootstrap services and controller services.
Acceptance Criteria
- When WICD is ran with the `bootstrap` command, all services within the service ConfigMap, with the bootstrap flag set to true, are started.
[WINC-713] Implement WICD bootstrap command
After discussion with staff engineer, we decided on a different approach to getting around earlier permission issues preventing getting ConfigMaps. We'll instead use a client authenticated using ServiceAccount credentials to allow WICD itself to get the services ConfigMaps from the cluster (introduced in https://github.com/openshift/windows-machine-config-operator/pull/1106). The CM data will be filtered to get the config for all bootstrap services. WMCO will pass in the proper version of ConfigMap to use as the source of truth when running the WICD `bootstrap` command.
PR has been updated to reflect this, tested, and is awaiting review.
To solve the problem of "how will the bootstrap command access the services ConfigMap data?", we decided we will pass in the encoded CM data as a string arg when WICD bootstrap is run by WMCO. A PR has been opened to update the health management enhancement to reflect this (https://github.com/openshift/enhancements/pull/1157).
This WMCO work for this story is up for review as well:
- the bootstrap command was added, unit tested, and manually tested
- Since the bootstrap command will run before a node object even exists, bootstrap services can't have any variables derived from a node object in its bin command. Logic was added to enforce that as part of the CM validation
(old account) Sebastian Soto
added a comment - The system:node kubeconfig does not have blanket permissions to pull ConfigMaps. See https://github.com/kubernetes/kubernetes/blob/bd190762fb77b78788e1a3ba72d70a8a08e184b8/plugin/pkg/auth/authorizer/node/node_authorizer.go#L175
The way this is implemented might have to be thought about more, since this is a one time operation, perhaps WMCO should copy the ConfigMap's bootstrap data to the VM.
(old account) Sebastian Soto
added a comment - The system:node kubeconfig does not have blanket permissions to pull ConfigMaps. See https://github.com/kubernetes/kubernetes/blob/bd190762fb77b78788e1a3ba72d70a8a08e184b8/plugin/pkg/auth/authorizer/node/node_authorizer.go#L175
The way this is implemented might have to be thought about more, since this is a one time operation, perhaps WMCO should copy the ConfigMap's bootstrap data to the VM.
PR and enhancement are both approved/lgtm-ed. Had to re-run CI since an unrelated PR (https://github.com/openshift/windows-machine-config-operator/pull/1086) went in finally and caused a merge conflict. And the ci-operator has some issues building the source code so this is still in CI... I've engaged test platform team.