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
Ensure KataConfigPoolSelector is used for PeerPodConfig CRD #305
Conversation
The peerpods config enablement is split into two parts - one part deals with creation of MachineConfigs before "kata-oc" MCP creation and another part deals with creation of PeerPodConfig CRD, runtimeclass and other misc configs after "kata-oc" MCP has updated. The reason for this split is to ensure that MachineConfigs are created before "kata-oc" creation so as to optimise the number of reboots required when applying MachineConfigs. Further, the relevant node labels are only available when "kata-oc" MCP is updated, thereby making it available for the creation of PeerPodConfig CRD Signed-off-by: Pradipta Banerjee <pradipta.banerjee@gmail.com>
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 just read through the code. I will do premerge testing if I get a change. Looks good to me.
if err != nil { | ||
r.Log.Info("Enabling peerpodconfig CR, runtimeclass etc", "err", err) | ||
// Give sometime for the error to go away before reconciling again | ||
return reconcile.Result{Requeue: true, RequeueAfter: 15 * time.Second}, err |
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 would suggest that in a situation where we know nothing about the nature or cause of an error, a more appropriate handling would be to rely on the exponential back-off provided by reconcile.Result{Requeue: true}
instead of a specific timeout which, considering the lack of information, has to be basically arbitrary.
But this will be a subject of a future PR to unify our reconciler return values so no need to change it now.
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.
lgtm thanks @bpradipt !
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.
lgtm, @bpradipt
The peerpods config enablement is split into two parts - one part deals with creation of MachineConfigs before "kata-oc" MCP creation and another part deals with creation of PeerPodConfig CRD, runtimeclass and other misc configs after "kata-oc" MCP has updated.
The reason for this split is to ensure that MachineConfigs are created before "kata-oc" creation so as to optimise the number of reboots required when applying MachineConfigs. Further, the relevant node labels are only available when "kata-oc" MCP is updated, thereby making it available for the creation of PeerPodConfig CRD
- Description of the problem which is fixed/What is the use case
The cloud-api-adaptor daemonset was not taking into account the KataConfigPoolSelector
Fixes: #KATA-1873
- What I did
Ensured KataConfigPoolSelector is made available to the PeerPodConfig CRD which is then used by the PeerPodConfig controller to start the cloud-api-adaptor daemonset on the proper nodes
- How to verify it
Create a KataConfig with custom KataConfigPoolSelector and ensure
enablePeerPods: true
. Verify that the cloud-api-adaptor pods are created only on the nodes matched via the KataConfigPoolSelector- Description for the changelog
Ensure KataConfigPoolSelector is used for PeerPodConfig CRD