OCPBUGS-13526: fix dynamic conversion webhook

[perdasilva]

operator-framework/operator-lifecycle-manager#2912

Signed-off-by: Tommy Hughes [email protected]

Description of the change:
With this change, relevant CRDs will properly retain dynamic conversion webhook settings in crd.spec.conversion.webhook.clientConfig.

Motivation for the change:
Currently, during a fresh install of an operator with conversion webhooks enabled, crd.spec.conversion.webhook.clientConfig is dynamically updated initially, as expected, with the proper webhook ns, name, & caBundle. However, within a few seconds, those critical settings are overwritten with the bundle’s packaged CRD conversion settings. This breaks the operator and stops the installation from completing successfully.

However, if that same operator version is installed as part of an upgrade from a prior release... the dynamic clientConfig settings are retained and all works as expected. This appears to be due to the differences in CSV status.phase progression.

Testing remarks:

Steps to Reproduce:

$ oc apply -f https://gist.githubusercontent.com/tchughesiv/0951d40f58f2f49306cc4061887e8860/raw/3c7979b58705ab3a9e008b45a4ed4abc3ef21c2b/conversionIssuesFreshInstall.yaml
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' -w

# Eventually, the clientConfig settings will revert to the following and stay that way.
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' 

map[service:map[name:dbaas-operator-webhook-service namespace:openshift-dbaas-operator path:/convert port:443]]

Post-fix:

The crd.spec.conversion.webhook.clientConfig should instead retain the following settings.

$ oc apply -f https://gist.githubusercontent.com/tchughesiv/0951d40f58f2f49306cc4061887e8860/raw/3c7979b58705ab3a9e008b45a4ed4abc3ef21c2b/conversionIssuesFreshInstall.yaml
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' 

map[caBundle:LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJoekNDQVMyZ0F3SUJBZ0lJZXdhVHNLS0hhbWd3Q2dZSUtvWkl6ajBFQXdJd0dERVdNQlFHQTFVRUNxxxxxxxxxxxxx service:map[name:dbaas-operator-controller-manager-service namespace:redhat-dbaas-operator path:/convert port:443]]

Additional info:

Oddly enough, currently if the operator is installed as an upgrade... instead of a fresh install... the webhook settings are properly/permanently set and everything works as expected. This can be tested in a fresh cluster like this.

$ oc apply -f https://gist.githubusercontent.com/tchughesiv/703109961f22ab379a45a401be0cf351/raw/2d0541b76876a468757269472e8e3a31b86b3c68/conversionWorksUpgrade.yaml
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' -w

Upstream-repository: operator-lifecycle-manager
Upstream-commit: 858c7cdb2f4cfe3d351225972aede54e3b114ce4

[openshift-ci-robot]

@perdasilva: This pull request references Jira Issue OCPBUGS-4991, which is invalid:

• expected the bug to target the "4.14.0" version, but it targets "4.13.0" instead
• expected the bug to be in one of the following states: NEW, ASSIGNED, POST, but it is MODIFIED instead

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

operator-framework/operator-lifecycle-manager#2912

Signed-off-by: Tommy Hughes [email protected]

Description of the change:
With this change, relevant CRDs will properly retain dynamic conversion webhook settings in crd.spec.conversion.webhook.clientConfig.

Motivation for the change:
Currently, during a fresh install of an operator with conversion webhooks enabled, crd.spec.conversion.webhook.clientConfig is dynamically updated initially, as expected, with the proper webhook ns, name, & caBundle. However, within a few seconds, those critical settings are overwritten with the bundle’s packaged CRD conversion settings. This breaks the operator and stops the installation from completing successfully.

However, if that same operator version is installed as part of an upgrade from a prior release... the dynamic clientConfig settings are retained and all works as expected. This appears to be due to the differences in CSV status.phase progression.

Testing remarks:

Steps to Reproduce:

$ oc apply -f https://gist.githubusercontent.com/tchughesiv/0951d40f58f2f49306cc4061887e8860/raw/3c7979b58705ab3a9e008b45a4ed4abc3ef21c2b/conversionIssuesFreshInstall.yaml
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' -w

# Eventually, the clientConfig settings will revert to the following and stay that way.
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' 

map[service:map[name:dbaas-operator-webhook-service namespace:openshift-dbaas-operator path:/convert port:443]]

Post-fix:

The crd.spec.conversion.webhook.clientConfig should instead retain the following settings.

$ oc apply -f https://gist.githubusercontent.com/tchughesiv/0951d40f58f2f49306cc4061887e8860/raw/3c7979b58705ab3a9e008b45a4ed4abc3ef21c2b/conversionIssuesFreshInstall.yaml
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' 

map[caBundle:LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJoekNDQVMyZ0F3SUJBZ0lJZXdhVHNLS0hhbWd3Q2dZSUtvWkl6ajBFQXdJd0dERVdNQlFHQTFVRUNxxxxxxxxxxxxx service:map[name:dbaas-operator-controller-manager-service namespace:redhat-dbaas-operator path:/convert port:443]]

Additional info:

Oddly enough, currently if the operator is installed as an upgrade... instead of a fresh install... the webhook settings are properly/permanently set and everything works as expected. This can be tested in a fresh cluster like this.

$ oc apply -f https://gist.githubusercontent.com/tchughesiv/703109961f22ab379a45a401be0cf351/raw/2d0541b76876a468757269472e8e3a31b86b3c68/conversionWorksUpgrade.yaml
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' -w

Upstream-repository: operator-lifecycle-manager
Upstream-commit: 858c7cdb2f4cfe3d351225972aede54e3b114ce4

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]

@perdasilva: This pull request references Jira Issue OCPBUGS-13526, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.14.0) matches configured target version for branch (4.14.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @kuiwang02

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

operator-framework/operator-lifecycle-manager#2912

Signed-off-by: Tommy Hughes [email protected]

Description of the change:
With this change, relevant CRDs will properly retain dynamic conversion webhook settings in crd.spec.conversion.webhook.clientConfig.

Motivation for the change:
Currently, during a fresh install of an operator with conversion webhooks enabled, crd.spec.conversion.webhook.clientConfig is dynamically updated initially, as expected, with the proper webhook ns, name, & caBundle. However, within a few seconds, those critical settings are overwritten with the bundle’s packaged CRD conversion settings. This breaks the operator and stops the installation from completing successfully.

However, if that same operator version is installed as part of an upgrade from a prior release... the dynamic clientConfig settings are retained and all works as expected. This appears to be due to the differences in CSV status.phase progression.

Testing remarks:

Steps to Reproduce:

$ oc apply -f https://gist.githubusercontent.com/tchughesiv/0951d40f58f2f49306cc4061887e8860/raw/3c7979b58705ab3a9e008b45a4ed4abc3ef21c2b/conversionIssuesFreshInstall.yaml
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' -w

# Eventually, the clientConfig settings will revert to the following and stay that way.
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' 

map[service:map[name:dbaas-operator-webhook-service namespace:openshift-dbaas-operator path:/convert port:443]]

Post-fix:

The crd.spec.conversion.webhook.clientConfig should instead retain the following settings.

$ oc apply -f https://gist.githubusercontent.com/tchughesiv/0951d40f58f2f49306cc4061887e8860/raw/3c7979b58705ab3a9e008b45a4ed4abc3ef21c2b/conversionIssuesFreshInstall.yaml
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' 

map[caBundle:LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJoekNDQVMyZ0F3SUJBZ0lJZXdhVHNLS0hhbWd3Q2dZSUtvWkl6ajBFQXdJd0dERVdNQlFHQTFVRUNxxxxxxxxxxxxx service:map[name:dbaas-operator-controller-manager-service namespace:redhat-dbaas-operator path:/convert port:443]]

Additional info:

Oddly enough, currently if the operator is installed as an upgrade... instead of a fresh install... the webhook settings are properly/permanently set and everything works as expected. This can be tested in a fresh cluster like this.

$ oc apply -f https://gist.githubusercontent.com/tchughesiv/703109961f22ab379a45a401be0cf351/raw/2d0541b76876a468757269472e8e3a31b86b3c68/conversionWorksUpgrade.yaml
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' -w

Upstream-repository: operator-lifecycle-manager
Upstream-commit: 858c7cdb2f4cfe3d351225972aede54e3b114ce4

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.

[perdasilva]

/retest

[kuiwang02]

/hold

I start to pre-verify it. after it is done, will unhold it if it is ok.

[kuiwang02]

/unhold
/label qe-approved

[m1kola]

Need to regenerate manifests. Other than that - looks good to me.

[m1kola]

@perdasilva this probably happened because you ran make manifests which sets OLM_VERSION to commit based versioning.

You need to run make verify-manifests (or make verify for everything) and commit changes. make verify-manifests sets a static 0.19.0 version:

operator-framework-olm/Makefile

Lines 153 to 155 in b85e891

	verify-manifests: OLM_VERSION=0.19.0 # set static version to avoid failing for commit based versioning
	verify-manifests: manifests
	$(MAKE) diff

[perdasilva]

Thank you!!!!

[perdasilva]

/retest

[perdasilva]

/retest

[perdasilva]

/test verify

[perdasilva]

/retest

[openshift-ci]

@perdasilva: 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.

[ankitathomas]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

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

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 [ankitathomas,perdasilva]

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

[openshift-ci-robot]

@perdasilva: Jira Issue OCPBUGS-13526: All pull requests linked via external trackers have merged:

• openshift/operator-framework-olm#490

Jira Issue OCPBUGS-13526 has been moved to the MODIFIED state.

In response to this:

operator-framework/operator-lifecycle-manager#2912

Signed-off-by: Tommy Hughes [email protected]

Description of the change:
With this change, relevant CRDs will properly retain dynamic conversion webhook settings in crd.spec.conversion.webhook.clientConfig.

Motivation for the change:
Currently, during a fresh install of an operator with conversion webhooks enabled, crd.spec.conversion.webhook.clientConfig is dynamically updated initially, as expected, with the proper webhook ns, name, & caBundle. However, within a few seconds, those critical settings are overwritten with the bundle’s packaged CRD conversion settings. This breaks the operator and stops the installation from completing successfully.

However, if that same operator version is installed as part of an upgrade from a prior release... the dynamic clientConfig settings are retained and all works as expected. This appears to be due to the differences in CSV status.phase progression.

Testing remarks:

Steps to Reproduce:

$ oc apply -f https://gist.githubusercontent.com/tchughesiv/0951d40f58f2f49306cc4061887e8860/raw/3c7979b58705ab3a9e008b45a4ed4abc3ef21c2b/conversionIssuesFreshInstall.yaml
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' -w

# Eventually, the clientConfig settings will revert to the following and stay that way.
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' 

map[service:map[name:dbaas-operator-webhook-service namespace:openshift-dbaas-operator path:/convert port:443]]

Post-fix:

The crd.spec.conversion.webhook.clientConfig should instead retain the following settings.

$ oc apply -f https://gist.githubusercontent.com/tchughesiv/0951d40f58f2f49306cc4061887e8860/raw/3c7979b58705ab3a9e008b45a4ed4abc3ef21c2b/conversionIssuesFreshInstall.yaml
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' 

map[caBundle:LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJoekNDQVMyZ0F3SUJBZ0lJZXdhVHNLS0hhbWd3Q2dZSUtvWkl6ajBFQXdJd0dERVdNQlFHQTFVRUNxxxxxxxxxxxxx service:map[name:dbaas-operator-controller-manager-service namespace:redhat-dbaas-operator path:/convert port:443]]

Additional info:

Oddly enough, currently if the operator is installed as an upgrade... instead of a fresh install... the webhook settings are properly/permanently set and everything works as expected. This can be tested in a fresh cluster like this.

$ oc apply -f https://gist.githubusercontent.com/tchughesiv/703109961f22ab379a45a401be0cf351/raw/2d0541b76876a468757269472e8e3a31b86b3c68/conversionWorksUpgrade.yaml
$ oc get crd dbaasproviders.dbaas.redhat.com --template '{{ .spec.conversion.webhook.clientConfig }}' -w

Upstream-repository: operator-lifecycle-manager
Upstream-commit: 858c7cdb2f4cfe3d351225972aede54e3b114ce4

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.

[perdasilva]

/cherry-pick release-4.15

[openshift-cherrypick-robot]

@perdasilva: new pull request could not be created: failed to create pull request against openshift/operator-framework-olm#release-4.15 from head openshift-cherrypick-robot:cherry-pick-490-to-release-4.15: status code 422 not one of [201], body: {"message":"Validation Failed","errors":[{"resource":"PullRequest","code":"custom","message":"No commits between openshift:release-4.15 and openshift-cherrypick-robot:cherry-pick-490-to-release-4.15"}],"documentation_url":"https://docs.github.com/rest/reference/pulls#create-a-pull-request"}

In response to this:

/cherry-pick release-4.15

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.

[perdasilva]

/cherry-pick release-4.14

[openshift-cherrypick-robot]

@perdasilva: new pull request could not be created: failed to create pull request against openshift/operator-framework-olm#release-4.14 from head openshift-cherrypick-robot:cherry-pick-490-to-release-4.14: status code 422 not one of [201], body: {"message":"Validation Failed","errors":[{"resource":"PullRequest","code":"custom","message":"No commits between openshift:release-4.14 and openshift-cherrypick-robot:cherry-pick-490-to-release-4.14"}],"documentation_url":"https://docs.github.com/rest/reference/pulls#create-a-pull-request"}

In response to this:

/cherry-pick release-4.14

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.

[perdasilva]

/cherry-pick release-4.13

[openshift-cherrypick-robot]

@perdasilva: new pull request created: #499

In response to this:

/cherry-pick release-4.13

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.