Bug 2009845: pkg/cvo/sync_worker: Log transition to updating #730
Conversation
openshift-ci
bot
added
the
approved
|
I don't see this log line during e2e-agnostic-update - do we expect this to show up during standard update? |
To make it easier to understand why this is happening.
wking
force-pushed
the
log-transition-to-updating
branch
from
0b80e08
to
8b95490
Compare
|
We do expect it during updates, but only from the pod that notices the transition to updating. That pod will bump the CVO Deployment to pull in a new CVO, and when that CVO comes up, it should go straight into updating over here. The most recent update presumit failed to install, but the previous round had: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_cluster-version-operator/730/pull-ci-openshift-cluster-version-operator-master-e2e-agnostic-upgrade/1486127605978501120/artifacts/e2e-agnostic-upgrade/gather-extra/artifacts/pods/openshift-cluster-version_cluster-version-operator-56487994b8-zc2n8_cluster-version-operator.log | grep 'ClusterVersionOperator\|Propagating initial target version\|Work changed\|Detected while\|Running sync.*in state' | head
I0126 01:46:07.179253 1 start.go:23] ClusterVersionOperator v1.0.0-754-g368ad0ef-dirty
I0126 01:46:08.502441 1 cvo.go:338] Starting ClusterVersionOperator with minimum reconcile period 2m8.765337491s
I0126 01:46:08.603980 1 sync_worker.go:255] Propagating initial target version { registry.build02.ci.openshift.org/ci-op-c5hfgrlk/release@sha256:bbfcf15fe6e61a4eaca0e38472506e7e119a785df88f6de56ede59ecbdbf585a true} to sync worker loop in state Updating.
I0126 01:46:08.604759 1 sync_worker.go:511] Detected while calculating next work: version change (from { false} to { registry.build02.ci.openshift.org/ci-op-c5hfgrlk/release@sha256:bbfcf15fe6e61a4eaca0e38472506e7e119a785df88f6de56ede59ecbdbf585a true})
I0126 01:46:08.604840 1 sync_worker.go:559] Running sync registry.build02.ci.openshift.org/ci-op-c5hfgrlk/release@sha256:bbfcf15fe6e61a4eaca0e38472506e7e119a785df88f6de56ede59ecbdbf585a (force=true) on generation 3 in state Updating at attempt 0
I0126 01:50:45.183322 1 sync_worker.go:559] Running sync registry.build02.ci.openshift.org/ci-op-c5hfgrlk/release@sha256:bbfcf15fe6e61a4eaca0e38472506e7e119a785df88f6de56ede59ecbdbf585a (force=true) on generation 3 in state Updating at attempt 1
I0126 01:56:27.608973 1 sync_worker.go:559] Running sync registry.build02.ci.openshift.org/ci-op-c5hfgrlk/release@sha256:bbfcf15fe6e61a4eaca0e38472506e7e119a785df88f6de56ede59ecbdbf585a (force=true) on generation 3 in state Reconciling at attempt 0We should be able to access the outgoing, change-noticing pod in Loki, but our update CI is dev-tips -> dev-tips + PR, so the outgoing CVO here lacks the logging code I'm trying to add. |
|
/retest |
wking
changed the title
openshift-ci
bot
added
bugzilla/severity-medium
|
@wking: This pull request references Bugzilla bug 2009845, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
Requesting review from QA contact: In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Lets see if test upgrade 4.10,https://github.com/openshift/cluster-version-operator/pull/730 4.11 would work |
A bit odd, but I guess it could be reworded later iiuc after update is done it would change Updating -> Reconciling, right? |
Yeah. I'm only logging both current and suggested incoming while we debug the
Yeah, but that happens in yet another location, which is not currently instrumented with logging. But it will have an empty |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jottofar, wking The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
this was an unrelated PDB issue; I don't think we need to wait out a retest. /override ci/prow/e2e-agnostic-upgrade |
|
@wking: Overrode contexts on behalf of wking: ci/prow/e2e-agnostic-upgrade In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
@wking: All pull requests linked via external trackers have merged:
Bugzilla bug 2009845 has been moved to the MODIFIED state. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
@wking: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
To make it easier to understand why this is happening.