-
Notifications
You must be signed in to change notification settings - Fork 55
operator API v1alpha2: revise Status #611
Comments
@avalluri please describe what you intend to do regarding the status field in the CRD. |
@pohly, here is the draft of the new status type roughly look:
I initially thout of including all sub-resources(roles, rolbebidnings, services, etc.) created for the deployment, but I am kind of decided to limit that to just keep node & controller driver status. |
Is the plan to have more than one entry with type "node"? If yes, how does the user know which node the status belongs to? If no, does it make sense to have How does the operator determine whether the "controller" or "node" is "ready"? You need to explain the semantic in your API, not just list the values. |
No, It is the combined state of all the node(s)/daemonset. The 'Reason' field supposed to hold the details of how many nodes are in running state out of total nodes.
The array was the result fo the initial design to hold all sub-resources state. Left like that, assuming that could be extendable to the original idea if needed. Otherwise, we can split into two entries - ControllerDriver and NodeDriver.
'Ready' here meaning that the Pods underneath the node DaemonSet, and StatefulSet are in 'Running' state. |
Revised the Deployment.Status to accommodate the deployment state conditions and driver state. Currently, Deployment has 3 conditions named CertsVerified, CertsReady, and DriverDeployed. It also records the summary of controller and node driver state, .i.e, no. of nodes the driver is running. In order to record real time status of the driver current had to rewrite the current reconcile loop. The existing reconcile loop was keen on the deployment CR changes and redeploy *only* the sub-objects that requires to redeploy. Instead the new reconcile logic *refresh* all the objects and CR status to keep the state consistent. The refresh chooses to merge patching the objects to avoid all unnecessary updates. There are two reconcile entry points: - CR reconcile loop: refreshes all the sub-objects and CR status - sub-object vent handler: redeploy only the deleted/changed resource and updates CR status if required. This also includes other code cleanups that come across. TODOs: - E2E tests for validating if the operator restores the state of a broken deployment - i.e, recovering deleted/modified sub-objects. FIXES: intel#611
Didn't make it into 0.8. Let's move it to 0.9. |
Revised the Deployment.Status to accommodate the deployment state conditions and driver state. Currently, Deployment has 3 conditions named CertsVerified, CertsReady, and DriverDeployed. It also records the summary of controller and node driver state, .i.e, no. of nodes the driver is running. In order to record real time status of the driver current had to rewrite the current reconcile loop. The existing reconcile loop was keen on the deployment CR changes and redeploy *only* the sub-objects that requires to redeploy. Instead the new reconcile logic *refresh* all the objects and CR status to keep the state consistent. The refresh chooses to merge patching the objects to avoid all unnecessary updates. There are two reconcile entry points: - CR reconcile loop: refreshes all the sub-objects and CR status - sub-object vent handler: redeploy only the deleted/changed resource and updates CR status if required. This also includes other code cleanups that come across. TODOs: - E2E tests for validating if the operator restores the state of a broken deployment - i.e, recovering deleted/modified sub-objects. FIXES: intel#611
Revised the Deployment.Status to accommodate the deployment state conditions and driver state. Currently, Deployment has 3 conditions named CertsVerified, CertsReady, and DriverDeployed. It also records the summary of controller and node driver state, .i.e, no. of nodes the driver is running. In order to record real time status of the driver current had to rewrite the current reconcile loop. The existing reconcile loop was keen on the deployment CR changes and redeploy *only* the sub-objects that requires to redeploy. Instead the new reconcile logic *refresh* all the objects and CR status to keep the state consistent. The refresh chooses to merge patching the objects to avoid all unnecessary updates. There are two reconcile entry points: - CR reconcile loop: refreshes all the sub-objects and CR status - sub-object vent handler: redeploy only the deleted/changed resource and updates CR status if required. This also includes other code cleanups that come across. FIXES: intel#611
We should align with kubernetes/enhancements#1624.
The text was updated successfully, but these errors were encountered: