Bug 1827822: Generation bug 4.3 #1485
Conversation
Problem:
If an operator is being upgraded that provides a required API whose GVK
has not changed since the previous version of the operator and
uses a skipRange instead of the Spec.Replaces field, OLM will:
* Add the new operator to the generation, and marking the APIs it
provides as "present".
* Remove the old operator from the generation, marking the APIs it
provides as "absent", despite being provided by the new version of the
operator.
* Attempt to resolve the "missing" APIs, overwriting the new version
of the operator with a copy that does not have its Spec.Replaces field
set.
This causes OLM to fail the upgrade, where the old operator's CSV will
not be replaced and the new operators CSV will run into an intercepting
API Provider issue.
Solution:
Update OLM to remove the old operator from the current generation before
adding the new operator to the generation.
openshift-ci-robot
added
the
bugzilla/severity-high
|
@awgreene: This pull request references Bugzilla bug 1827822, which is invalid:
Comment 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. |
openshift-ci-robot
added
the
bugzilla/invalid-bug
awgreene
force-pushed
the
generation-bug-4.3
branch
2 times, most recently
from
7dea9bb
to
5f45557
Compare
Problem: In an upgrade where v1 of Operator A provides an API and v1 of Operator B depends on the API, where the ownership of the API is transferred from Operator A to Operator B during the upgrade, OLM may run into a situation where Operator B is updated first. This causes OLM to fail to calculate the generation because multiple operator provide the same API. Solution: Add and remove updates as a set to prevent the situation described above.
awgreene
force-pushed
the
generation-bug-4.3
branch
from
5f45557
to
70a8441
Compare
|
/retest |
|
/test e2e-gcp-upgrade |
|
/retest |
|
/approve |
|
/lgtm |
|
/bugzilla refresh Recalculating validity in case the underlying Bugzilla bug has changed. |
|
@openshift-bot: This pull request references Bugzilla bug 1827822, which is invalid:
Comment 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. |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: awgreene, kevinrizza, njhale 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 |
openshift-ci-robot
added
the
approved
|
/bugzilla refresh Recalculating validity in case the underlying Bugzilla bug has changed. |
|
@openshift-bot: This pull request references Bugzilla bug 1827822, which is invalid:
Comment 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. |
|
/bugzilla refresh Recalculating validity in case the underlying Bugzilla bug has changed. |
|
@openshift-bot: This pull request references Bugzilla bug 1827822, which is invalid:
Comment 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. |
|
/bugzilla refresh Recalculating validity in case the underlying Bugzilla bug has changed. |
|
@openshift-bot: This pull request references Bugzilla bug 1827822, which is invalid:
Comment 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. |
|
/bugzilla refresh Recalculating validity in case the underlying Bugzilla bug has changed. |
openshift-ci-robot
added
bugzilla/valid-bug
|
@openshift-bot: This pull request references Bugzilla bug 1827822, 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. 6 validation(s) were run on this bug
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. |
sdodson
added
the
cherry-pick-approved
|
/retest Please review the full test history for this PR and help us cut down flakes. |
9 similar comments
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
@awgreene: All pull requests linked via external trackers have merged: operator-framework/operator-lifecycle-manager#1485. Bugzilla bug 1827822 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. |
|
/cherry-pick release-4.2 |
|
@ecordell: new pull request created: #1526 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. |
This PR fixes two issues with OLM's "Generation Calculator":
Problem:
If an operator is being upgraded that provides a required API whose GVK
has not changed since the previous version of the operator and
uses a skipRange instead of the Spec.Replaces field, OLM will:
Add the new operator to the generation, and marking the APIs it
provides as "present".
Remove the old operator from the generation, marking the APIs it
provides as "absent", despite being provided by the new version of the
operator.
Attempt to resolve the "missing" APIs, overwriting the new version
of the operator with a copy that does not have its Spec.Replaces field
set.
This causes OLM to fail the upgrade, where the old operator's CSV will
not be replaced and the new operators CSV will run into an intercepting
API Provider issue.
Solution:
Update OLM to remove the old operator from the current generation before
adding the new operator to the generation.
Problem:
In an upgrade where v1 of Operator A provides an API and v1 of Operator
B depends on the API, where the ownership of the API is transferred from
Operator A to Operator B during the upgrade, OLM may run into a
situation where Operator B is updated first. This causes OLM to fail to
calculate the generation because multiple operator provide the same
API.
Solution:
Add and remove updates as a set to prevent the situation described
above.