Full logs, raw output, and troubleshooting notes for the OCPBUGS-88531 test verification.
| Management Cluster | AWS (via KUBECONFIG=/Users/brcox/aws_dev_kubeconfig) |
|---|---|
| HostedCluster | brcox-sm-dev-hc (namespace: clusters) |
| HCP Namespace | clusters-brcox-sm-dev-hc |
| Platform | Azure |
| OCP Version | 4.22.0-rc.3 |
| CNO Image | (fill in after image build completes) |
| PR | #3030 |
| JIRA | OCPBUGS-88531 |
# Command used:
# for deploy in cloud-network-config-controller multus-admission-controller network-node-identity ovnkube-control-plane; do
# echo "=== $deploy ==="
# oc get deploy -n clusters-brcox-sm-dev-hc $deploy -o jsonpath='{.spec.template.metadata.annotations}' | jq .
# done
# oc get hcp -n clusters-brcox-sm-dev-hc brcox-sm-dev-hc -o jsonpath='{.metadata.annotations}' | jq .
CNO uses a 3-minute ResyncPeriod. After setting the restart-date annotation on the HostedCluster, expect up to 3 minutes before CNO picks up the change and triggers a rollout.
CNO uses deterministic manifests with server-side apply. If the restart-date value is unchanged between reconciles, the pod template annotation stays identical, so Kubernetes does not trigger a new rollout. This is the expected idempotent behavior tested in Scenario 4.
The cloud-network-config-controller is only deployed on AWS, Azure, GCP, and OpenStack with OVN networking. On KubeVirt or None platform, there is no CNCC pod to restart, but SetRestartDateAnnotation still processes all rendered objects — there are simply no CNCC manifests to annotate.