-
Notifications
You must be signed in to change notification settings - Fork 544
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug 1740174: fix(catalog): re-install resources in existing installplan #977
Bug 1740174: fix(catalog): re-install resources in existing installplan #977
Conversation
This specifically fixes the scenario where a subscription is deleted and recreated in a namespace with an additional subscription. When the subscription of interest is deleted, the associated installplan remains due to the other subscription's owner reference. Because the existing installplan manifests match, no additional work is done. This is a problem if resources that were originally installed have been deleted. Now after a subscription is recreated, the proper owner references are re-added onto the install plan as well as all the resources are checked that they are installed.
@jpeeler: This pull request references a valid Bugzilla bug. 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. 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. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ecordell, jpeeler 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 |
I don't see an associated BZ for the parent PR. That needs to be created and then verified by QE before I can merge this. |
@crawford The original BZ was filed only against 4.1, should we clone the bug so there's one for 4.1 and 4.2? |
@ecordell You need a bug filed against 4.1.z and 4.2. Typically, the bug against 4.2 gets filed first and then the 4.1.z bug is cloned from that. Once QE has verified the 4.2 bug on the master branch, we can cherry-pick it into the release branch. |
@jpeeler: This pull request references an invalid Bugzilla bug:
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. |
@jpeeler we're waiting for QE to verify the parent bug against 4.2, then this will be ready to merge. |
QE has verified the 4.2 fix now (https://bugzilla.redhat.com/show_bug.cgi?id=1714140). |
@crawford should be good to go now |
/bugzilla refresh |
@shawn-hurley: This pull request references a valid Bugzilla bug. 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. 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. |
@derekwaynecarr I think you're handling backport approvals now? |
/test unit |
@jpeeler: All pull requests linked via external trackers have merged. Bugzilla bug 1740174 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. |
This specifically fixes the scenario where a subscription is deleted and recreated in a namespace with an additional subscription. When the subscription of interest is deleted, the associated installplan remains due to the other subscription's owner reference. Because the existing installplan manifests match, no additional work is done. This is a problem if resources that were originally installed have been deleted.
Now after a subscription is recreated, the proper owner references are re-added onto the install plan as well as all the resources are checked that they are installed.
(Cherry pick of #965.)