OCPBUGS-38342: UPSTREAM: <carry>: allow type mutation for specific secrets - revert

[vrutkovs]

This reverts commit b9c1d7e. Drop carry from #1924

This is no longer necessary as all these secrets have been migrated during 4.15 upgrade

[openshift-ci-robot]

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

Requesting review from QA contact:
/cc @wangke19

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

In response to this:

This reverts commit b9c1d7e. Drop carry from #1924

This is no longer necessary as all these secrets have been migrated during 4.15 upgrade

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]

@vrutkovs: the contents of this pull request could not be automatically validated.

The following commits could not be validated and must be approved by a top-level approver:

• 3a5a4c9|Revert "UPSTREAM: : allow type mutation for specific secrets": does not specify an upstream backport in the commit message

Comment /validate-backports to re-evaluate validity of the upstream PRs, for example when they are merged upstream.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: vrutkovs
Once this PR has been reviewed and has the lgtm label, please assign tkashem for approval. For more information see the Kubernetes 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:

• DOWNSTREAM_OWNERS

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

[vrutkovs]

/cc @atiratree

[p0lyn0mial]

This is no longer necessary as all these secrets have been migrated during 4.15 upgrade

@vrutkovs note that some secret could have been created with the old type on 4.16 (for example openshift/library-go#1773 (comment)).

Before removing this carry we should ensure that these secrets were migrated to the new type as well.

[vrutkovs]

some secret could have been created with the old type on 4.16

Using SecretTypeTLS is still valid - and you can create those secrets.

However controllers should not be using library-go's applySecret/applyConfigMap when managing those - this would change their type forcibly. This was fixed by several PRs:

• ensuring all new secrets are created with kubernetes.io/tls type (in etcd and kcm)
• born-in-4.6 upgraded to 4.15 and have this type changed before upgrading to 4.16+

So this carry can be safely removed in 4.16+

[p0lyn0mial]

Personally, I would feel more comfortable if we could create a new control loop in KAS-O that produces a metric, which we could then scrape via telemetry, before removing this carry path. What do you think?

/cc @tkashem

[openshift-ci]

@vrutkovs: 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-aws-ovn-serial	3a5a4c9	link	true	/test e2e-aws-ovn-serial
ci/prow/verify-commits	3a5a4c9	link	true	/test verify-commits
ci/prow/e2e-gcp-ovn-upgrade	3a5a4c9	link	true	/test e2e-gcp-ovn-upgrade

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.

[vrutkovs]

we could create a new control loop in KAS-O that produces a metric, which we could then scrape via telemetry

most clusters are disconnected, so we'll miss a lot of clusters. Also, we'd need customers to updated before we can assess the situation - that might take ~year. Another thing I'm concerned are false-positives - cluster admins may accidentally create such secrets in the namespaces and the metric would mistakenly show these secrets

[tkashem]

most clusters are disconnected, so we'll miss a lot of clusters. Also, we'd need customers to updated before we can assess the situation - that might take ~year. Another thing I'm concerned are false-positives - cluster admins may accidentally create such secrets in the namespaces and the metric would mistakenly show these secrets

• through insight we will know about the connected clusters, that will be a good piece of data based on which we can decide
• I don't think we need to be concerned with the false positives, our focus is known secret objects in certain namespaces, right?

In my humble opinion, I would feel safer to gather some data before we remove this patch. If we use insight to look at some old clusters that started with 4.6 (i don't remember the exact version) that would give us some confidence, If not through insight, the least we can do is identify some of these clusters, get in touch with the customer and ask them to run a diagnostics we provide. Thoughts?

[vrutkovs]

that will be a good piece of data

It would be incomplete data and would not prevent possible failures. We might as well rely on QE doing 4.6 -> 4.16 upgrade.

our focus is known secret objects in certain namespaces, right?

We don't limit validation rule to specific secret names, just the namespaces - so if user has created new SecretTypeTLS in the namespaces it would still be converted - and reported. What we would not know is if these secrets are critical to cluster functionality and will cause upgrade failures