OCPBUGS-60162: reject byo vpc/subnets with CAPI owned cluster tag

[tthvo]

This adds an additional check for CAPI owned cluster tag sigs.k8s.io/cluster-api-provider-aws/cluster/<id>:owned.

Since the destroy code is also searching for this tag to clean up cluster resources, it is reasonable to safe-guard against this case.

References (metadata.json)

installer/pkg/asset/cluster/aws/aws.go

Lines 30 to 32 in d0aabcc

	{fmt.Sprintf("kubernetes.io/cluster/%s", infraID): "owned"},
	{"openshiftClusterID": clusterID},
	{fmt.Sprintf("sigs.k8s.io/cluster-api-provider-aws/cluster/%s", infraID): "owned"},

Notes

It seems unlikely that a vpc/subnet has a tag sigs.k8s.io/cluster-api-provider-aws/cluster/<id>:owned but doesn't have the corresponding kubernetes.io/cluster/<id>:owned tag... 💭

But "unlikely" does not mean it won't happen and the destroy code is also searching that CAPA tag. So, I thought we could just add this additional check.

The tag search order is:

1. kubernetes.io/cluster/<id>:owned
2. sigs.k8s.io/cluster-api-provider-aws/cluster/<id>:owned if none is found in 1.

[openshift-ci-robot]

@tthvo: This pull request references Jira Issue OCPBUGS-60162, 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.20.0) matches configured target version for branch (4.20.0)
• bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)

No GitHub users were found matching the public email listed for the QA contact in Jira ([email protected]), skipping review request.

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

In response to this:

This adds an additional check for CAPI owned cluster tag sigs.k8s.io/cluster-api-provider-aws/cluster/:owned.

Since the destroy code is also searching for this tag to clean up cluster resources[1], it is reasonable to safe-guard against this case.

References (metadata.json)

installer/pkg/asset/cluster/aws/aws.go

Lines 30 to 32 in d0aabcc

	{fmt.Sprintf("kubernetes.io/cluster/%s", infraID): "owned"},
	{"openshiftClusterID": clusterID},
	{fmt.Sprintf("sigs.k8s.io/cluster-api-provider-aws/cluster/%s", infraID): "owned"},

Notes

It seems unlikely that a vpc/subnet has a tag sigs.k8s.io/cluster-api-provider-aws/cluster/<id>:owned but doesn't have the corresponding kubernetes.io/cluster/<id>:owned tag... 💭

But "unlikely" does not mean it won't happen and the destroy code is also searching that CAPA tag. So, I thought we could just add this additional check.

The tag search order is:

1. kubernetes.io/cluster/<id>:owned
2. sigs.k8s.io/cluster-api-provider-aws/cluster/<id>:owned if none is found in 1.

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]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign tthvo for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• pkg/asset/installconfig/aws/OWNERS

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

[tthvo]

/cc @yunjiang29

[openshift-ci-robot]

@tthvo: This pull request references Jira Issue OCPBUGS-60162, which is valid.

3 validation(s) were run on this bug

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

No GitHub users were found matching the public email listed for the QA contact in Jira ([email protected]), skipping review request.

In response to this:

This adds an additional check for CAPI owned cluster tag sigs.k8s.io/cluster-api-provider-aws/cluster/<id>:owned.

Since the destroy code is also searching for this tag to clean up cluster resources, it is reasonable to safe-guard against this case.

References (metadata.json)

installer/pkg/asset/cluster/aws/aws.go

Lines 30 to 32 in d0aabcc

	{fmt.Sprintf("kubernetes.io/cluster/%s", infraID): "owned"},
	{"openshiftClusterID": clusterID},
	{fmt.Sprintf("sigs.k8s.io/cluster-api-provider-aws/cluster/%s", infraID): "owned"},

Notes

It seems unlikely that a vpc/subnet has a tag sigs.k8s.io/cluster-api-provider-aws/cluster/<id>:owned but doesn't have the corresponding kubernetes.io/cluster/<id>:owned tag... 💭

But "unlikely" does not mean it won't happen and the destroy code is also searching that CAPA tag. So, I thought we could just add this additional check.

The tag search order is:

1. kubernetes.io/cluster/<id>:owned
2. sigs.k8s.io/cluster-api-provider-aws/cluster/<id>:owned if none is found in 1.

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]

@tthvo: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-azure-ovn-resourcegroup	821253f	link	false	/test e2e-azure-ovn-resourcegroup
ci/prow/e2e-aws-custom-dns-techpreview	821253f	link	false	/test e2e-aws-custom-dns-techpreview
ci/prow/okd-scos-e2e-aws-ovn	821253f	link	false	/test okd-scos-e2e-aws-ovn
ci/prow/e2e-vsphere-ovn-multi-network	821253f	link	false	/test e2e-vsphere-ovn-multi-network
ci/prow/e2e-aws-ovn-heterogeneous	821253f	link	false	/test e2e-aws-ovn-heterogeneous
ci/prow/e2e-vsphere-host-groups-ovn-techpreview	821253f	link	false	/test e2e-vsphere-host-groups-ovn-techpreview

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.