Bypass validate update

[bshephar]

This change allows for the ValidateUpdate() webhook to be bypassed. This provides functionality for advanced use cases where the user has independently validated that their update won't break the deployment, or orphan any data in an old database.

It's anticipated that this functionality will be required in cases where we deploy the control plane and point it at an existing database. Then perform a database migration, in which case we want to redirect the Heat deployment to the new database.

Since this operation is inherently dangerous. By default, this is an undocumented feature that is intended to facilitate situations where users are confident in the operation they are performing.

[stuggi]

just pasting here for reference on what we did in the infra https://github.com/openstack-k8s-operators/infra-operator/blob/main/apis/network/v1beta1/ipset_webhook.go#L102 to make sure there is a required manual extra step if the ipset was intended to be immutable.

[stuggi]

if we go this way using an annotation, maybe this should be not a heat specific annotation, so the same can be used on other service operators CRs as this seems to be a functionality we'd then want to have across all service operators?

[bshephar]

Yeah, my intention here is to establish a design pattern we're happy with. I see infra-operator is using a field in the Spec section to determine this. It feels a lot like the advancedMode proposed on placement-operator. I think I would prefer to be more specific with these regardless of whether we use annotations or the spec fields, see the discussion here:
openstack-k8s-operators/placement-operator#17 (comment)

So I would propose that we either:
a) use the annotations but make them feature specific, which would mean changing the string in this PR to:
HeatDatabaseMigrationAnnotation = "heat.openstack.org/database-migration"

Or b)
Like I mentioned in that comment on the placement-operator, using feature sets that can be enabled or disabled depending on the customers use case:
spec.enabledFeatures.databaseMigration

I'm not sure Immutabe is the best choice of adjective since large portions of the spec will indeed be mutable. It's very specific parts that we would ultimately like to protect. So something more specific to those use cases feels like a better fit.

[bshephar]

I just updated the PR here to change this Const and string to be reflective of my comment.

Both the enabledFeatures and annotations proposals have been established as patterns for user interfaces that change the behaviour of operators in OpenShift as well. With examples being featureSets and Gates:
https://docs.openshift.com/container-platform/4.13/nodes/clusters/nodes-cluster-enabling-features.html

And if you want to delete a specific node from the machine-api, you can use an annotation to do that on the node:
https://github.com/openshift/machine-api-operator/blob/release-4.14/pkg/controller/machineset/delete_policy.go#L32-L34

So I think either of these proposals would be familiar and intuitive for users of OpenShift.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bshephar, slagle

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 [bshephar]

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