OCPEDGE-1126: Rebase LVMS in replacement of topolvm

[jakobmoellerdev]

TODO:

• Generate Lister / Typed Clients due to otherwise mandatory import on lvm-operator introducing tons of dependencies replaced with a generic unstructured client
• Resolve vendor conflict (see above) with normal resolution instead of vendor patch resolved by using dynamic client with discovery API for LVMCluster
• Create Cleanup Scenario that deletes old set of resources from installations that were present in 4.15/4.16
• Add upgrade test scenario to verify that LVMS works as expected
• Add webhook yaml generation as part of the rebase script so that the validatingwebhook configuration is applied to LVMCluster normally added opinionated webhook generation with notes for further maintenance
• Use 4.17 Candidate instead of late 4.16 candidate once we have a CPaaS build out in the wild (need to trigger external replication that can be used during 4.17 testing cycle) rebased on 4.17 candidate replicated to quay as aligned. Binaries / shas are equivalent and once release is happening we just need to retrigger the rebase script with the registry.redhat.io url before pushing out the candidate for Microshift. Since the images are the same this is however not endangering breaking anything.
• Add dynamic lvmd.yaml resolution via symlink into /var/lib/microshift/lvms/lvmd.yaml
• Rebase on main (seems I have to do this a lot)

[openshift-ci-robot]

@jakobmoellerdev: This pull request references OCPEDGE-1126 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

In response to this:

TODO:

• Generate Lister / Typed Clients due to otherwise mandatory import on lvm-operator introducing tons of dependencies
• Resolve vendor conflict (see above) with normal resolution instead of vendor patch
• Create Cleanup Scenario that deletes old set of resources from installations that were present in 4.15/4.16
• Add upgrade test scenario to verify that LVMS works as expected
• Add webhook yaml generation as part of the rebase script so that the validatingwebhook configuration is applied to LVMCluster normally

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci-robot]

@jakobmoellerdev: This pull request references OCPEDGE-1126 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

In response to this:

TODO:

• Generate Lister / Typed Clients due to otherwise mandatory import on lvm-operator introducing tons of dependencies
• Resolve vendor conflict (see above) with normal resolution instead of vendor patch
• Create Cleanup Scenario that deletes old set of resources from installations that were present in 4.15/4.16
• Add upgrade test scenario to verify that LVMS works as expected
• Add webhook yaml generation as part of the rebase script so that the validatingwebhook configuration is applied to LVMCluster normally
• Use 4.17 Candidate instead of late 4.16 candidate once we have a CPaaS build out in the wild (need to trigger external replication that can be used during 4.17 testing cycle)

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@jakobmoellerdev: This pull request references OCPEDGE-1126 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

In response to this:

TODO:

• Generate Lister / Typed Clients due to otherwise mandatory import on lvm-operator introducing tons of dependencies
• Resolve vendor conflict (see above) with normal resolution instead of vendor patch
• Create Cleanup Scenario that deletes old set of resources from installations that were present in 4.15/4.16
• Add upgrade test scenario to verify that LVMS works as expected
• Add webhook yaml generation as part of the rebase script so that the validatingwebhook configuration is applied to LVMCluster normally
• Use 4.17 Candidate instead of late 4.16 candidate once we have a CPaaS build out in the wild (need to trigger external replication that can be used during 4.17 testing cycle)
• Rebase on main

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@jakobmoellerdev: This pull request references OCPEDGE-1126 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

In response to this:

TODO:

• Generate Lister / Typed Clients due to otherwise mandatory import on lvm-operator introducing tons of dependencies replaced with a generic unstructured client
• Resolve vendor conflict (see above) with normal resolution instead of vendor patch
• Create Cleanup Scenario that deletes old set of resources from installations that were present in 4.15/4.16
• Add upgrade test scenario to verify that LVMS works as expected
• Add webhook yaml generation as part of the rebase script so that the validatingwebhook configuration is applied to LVMCluster normally
• Use 4.17 Candidate instead of late 4.16 candidate once we have a CPaaS build out in the wild (need to trigger external replication that can be used during 4.17 testing cycle)
• Rebase on main

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@jakobmoellerdev: This pull request references OCPEDGE-1126 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

In response to this:

TODO:

• Generate Lister / Typed Clients due to otherwise mandatory import on lvm-operator introducing tons of dependencies replaced with a generic unstructured client
• Resolve vendor conflict (see above) with normal resolution instead of vendor patch
• Create Cleanup Scenario that deletes old set of resources from installations that were present in 4.15/4.16
• Add upgrade test scenario to verify that LVMS works as expected
• Add webhook yaml generation as part of the rebase script so that the validatingwebhook configuration is applied to LVMCluster normally
• Use 4.17 Candidate instead of late 4.16 candidate once we have a CPaaS build out in the wild (need to trigger external replication that can be used during 4.17 testing cycle)
• Rebase on main

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@jakobmoellerdev: This pull request references OCPEDGE-1126 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

In response to this:

TODO:

• Generate Lister / Typed Clients due to otherwise mandatory import on lvm-operator introducing tons of dependencies replaced with a generic unstructured client
• Resolve vendor conflict (see above) with normal resolution instead of vendor patch
• Create Cleanup Scenario that deletes old set of resources from installations that were present in 4.15/4.16
• Add upgrade test scenario to verify that LVMS works as expected
• Add webhook yaml generation as part of the rebase script so that the validatingwebhook configuration is applied to LVMCluster normally
• Use 4.17 Candidate instead of late 4.16 candidate once we have a CPaaS build out in the wild (need to trigger external replication that can be used during 4.17 testing cycle)
• Add dynamic lvmd.yaml resolution via symlink into /var/lib/microshift/lvms/lvmd.yaml
• Rebase on main

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 openshift-eng/jira-lifecycle-plugin repository.

[copejon]

/cc @copejon

[openshift-ci-robot]

@jakobmoellerdev: This pull request references OCPEDGE-1126 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

In response to this:

TODO:

• Generate Lister / Typed Clients due to otherwise mandatory import on lvm-operator introducing tons of dependencies replaced with a generic unstructured client
• Resolve vendor conflict (see above) with normal resolution instead of vendor patch
• Create Cleanup Scenario that deletes old set of resources from installations that were present in 4.15/4.16
• Add upgrade test scenario to verify that LVMS works as expected
• Add webhook yaml generation as part of the rebase script so that the validatingwebhook configuration is applied to LVMCluster normally
• Use 4.17 Candidate instead of late 4.16 candidate once we have a CPaaS build out in the wild (need to trigger external replication that can be used during 4.17 testing cycle)
• Add dynamic lvmd.yaml resolution via symlink into /var/lib/microshift/lvms/lvmd.yaml
• Rebase on main

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 openshift-eng/jira-lifecycle-plugin repository.

[jakobmoellerdev]

Putting up as ready for review now even though cleanup discussion is still pending

[openshift-ci-robot]

@jakobmoellerdev: This pull request references OCPEDGE-1126 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

In response to this:

TODO:

• Generate Lister / Typed Clients due to otherwise mandatory import on lvm-operator introducing tons of dependencies replaced with a generic unstructured client
• Resolve vendor conflict (see above) with normal resolution instead of vendor patch
• Create Cleanup Scenario that deletes old set of resources from installations that were present in 4.15/4.16
• Add upgrade test scenario to verify that LVMS works as expected
• Add webhook yaml generation as part of the rebase script so that the validatingwebhook configuration is applied to LVMCluster normally
• Use 4.17 Candidate instead of late 4.16 candidate once we have a CPaaS build out in the wild (need to trigger external replication that can be used during 4.17 testing cycle)
• Add dynamic lvmd.yaml resolution via symlink into /var/lib/microshift/lvms/lvmd.yaml
• Rebase on main

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 openshift-eng/jira-lifecycle-plugin repository.

[jakobmoellerdev]

/hold

[pmtk]

Just to be sure. AFAIK the context cancelation doesn't propagate back to parents, right?
So, if we get some error while watching, it won't be propagated back to main thread and MicroShift will continue running without hot reloading. Is that correct?

[jakobmoellerdev]

thats right, cancel will only cancel the context return from context.WithCancelCause, not the parent ctx. Ive tried this and tested around and microshift ctx keeps on running

[copejon]

A couple nits, but nothing to hold up the PR over

[copejon]

Looks great!

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: copejon, jakobmoellerdev

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:

• OWNERS [copejon]

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

[openshift-ci]

@jakobmoellerdev: 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-sigs/prow repository. I understand the commands that are listed here.