Skip to content

Downstream Sync 04.13#289

Merged
openshift-merge-robot merged 8 commits intoopenshift:masterfrom
perdasilva:sync_04_13
Apr 14, 2022
Merged

Downstream Sync 04.13#289
openshift-merge-robot merged 8 commits intoopenshift:masterfrom
perdasilva:sync_04_13

Conversation

@perdasilva
Copy link
Copy Markdown
Contributor

@perdasilva perdasilva commented Apr 13, 2022

This is a downstream sync PR taking the latest and greatest from the upstream back down, including the fail forward feature for 4.11

Signed-off-by: timflannagan <timflannagan@gmail.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: c5ef8b448cef4c83e3a5f542aad449e1e60b1857
@openshift-ci openshift-ci Bot requested review from exdx and kevinrizza April 13, 2022 12:01
@openshift-ci openshift-ci Bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 13, 2022
@perdasilva
Copy link
Copy Markdown
Contributor Author

/test e2e-gcp-olm-flaky
/test e2e-gcp-console-olm
/test e2e-upgrade

@timflannagan
Copy link
Copy Markdown
Contributor

We can use this as a placeholder for the SD Epic work.

/hold

@openshift-ci openshift-ci Bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 13, 2022
oceanc80 and others added 2 commits April 13, 2022 19:57
Signed-off-by: Catherine Chan-Tse <cchantse@redhat.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: f8d7f78b2f8db6f01c0651d5072742752c69663d
Signed-off-by: Per Goncalves da Silva <pegoncal@redhat.com>

Co-authored-by: Per Goncalves da Silva <pegoncal@redhat.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 8abe078086bba81e2765a244b5a16fe1196f0f7c
@perdasilva
Copy link
Copy Markdown
Contributor Author

/test e2e-gcp-olm-flaky

awgreene and others added 5 commits April 14, 2022 17:42
This commit introduces the upgradeStrategy field to the operatorGroup
type. The upgradeStrategy field defines OLM behavior when upgrading
operators in the namespace. Two upgrade strategies are currently
supported, "Default" and "TechPreviewUnsafeFailForward".

The "Default" strategy mimics existing behavior.

The "TechPreviewUnsafeFailForward" strategy allows users to recover
from failed installPlans or failed clusterServiceVersions, it should
be noted that these upgrades are unsafe and can lead to unpredictable
behavior and potentially dataloss.

Upstream-repository: api
Upstream-commit: 33310d6154f344da5494c788451bd34cdf54711c
Signed-off-by: Alexander Greene <greene.al1991@gmail.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 63c09814cbb9cb6c904492e92c4a906167c5e8de
This commit introduces OLM support for fail forward upgrades. Existing
upgrade behavior is now defined as "Default" upgrade behavior. A new
upgrade strategy referred to as UnsafeFailForward has been introduced
in a tech preview state. When fail forward upgrades are enabled, CSVs
will now be able to move from the failed state to the replacing state,
effectively allowing operators in a namespace to fail forward from
failed installs or upgrades. Additionally, it will be possible to
recover from failed installPlans by updating the upgrade graph defined
in the catalog. Fail forward upgrades are generally unsafe and
unsupported as they could result in unexpected behavior or lost data
due to the fact that critical version of an operator may not be
visited.

Signed-off-by: Alexander Greene <greene.al1991@gmail.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 9d6e88c418c627afde7e32d4b7df456c55a56450
Co-authored-by: Ankita Thomas <ankithom@redhat.com>
Co-authored-by: timflannagan <timflannagan@gmail.com>
Signed-off-by: timflannagan <timflannagan@gmail.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 918a4d1d40b53605e3889fb6ddeff60c455c248c
Signed-off-by: timflannagan <timflannagan@gmail.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 73a2b072172e34b036ebe9fa83b1a6a5bb3259a3
@perdasilva
Copy link
Copy Markdown
Contributor Author

/hold cancel - let's get this merged!

@openshift-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Apr 14, 2022
@timflannagan
Copy link
Copy Markdown
Contributor

/hold cancel

@openshift-ci openshift-ci Bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 14, 2022
@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented Apr 14, 2022

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: perdasilva, timflannagan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:
  • OWNERS [perdasilva,timflannagan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@perdasilva
Copy link
Copy Markdown
Contributor Author

/test e2e-gcp-console-olm
/test e2e-gcp-olm

@timflannagan
Copy link
Copy Markdown
Contributor

/retest-required

@perdasilva
Copy link
Copy Markdown
Contributor Author

/test e2e-gcp-olm-flaky

1 similar comment
@perdasilva
Copy link
Copy Markdown
Contributor Author

/test e2e-gcp-olm-flaky

@perdasilva
Copy link
Copy Markdown
Contributor Author

/test e2e-upgrade

@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented Apr 14, 2022

@perdasilva: all tests passed!

Full PR test history. Your PR dashboard.

Details

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.

@openshift-merge-robot openshift-merge-robot merged commit cd2e995 into openshift:master Apr 14, 2022
stevekuznetsov added a commit to stevekuznetsov/operator-framework-olm that referenced this pull request Aug 3, 2023
We want to use a partial object metadata query for CSVs to reduce
resource utilization. We still want to ask questions about whether these
CSVs are copied, so we need to refactor this method to take only object
metadata. While it's not a perfect port of the previous logic, it defies
explanation how an object would have all the other markings of being
copied but the wrong status.

Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
Upstream-repository: api
Upstream-commit: 409ec70c6c889945acb0447397305aa5c2150ea2
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants