API-1674: Add ownership annotations to new and existing olm-managed secrets #626
Conversation
dinhxuanvu
force-pushed
the
cert-annotations
branch
from
4436921
to
988598e
Compare
openshift-ci
bot
added
the
approved
dinhxuanvu
force-pushed
the
cert-annotations
branch
from
988598e
to
050689d
Compare
openshift-merge-robot
added
the
needs-rebase
dinhxuanvu
force-pushed
the
cert-annotations
branch
2 times, most recently
from
43986c1
to
2c514bb
Compare
openshift-merge-robot
removed
the
needs-rebase
dinhxuanvu
force-pushed
the
cert-annotations
branch
3 times, most recently
from
7f08f40
to
554becb
Compare
|
This contains non-upstreamed changes to the staging directory. Because of that, it needs to be marked specially. I believe |
dinhxuanvu
force-pushed
the
cert-annotations
branch
from
554becb
to
7eecf8c
Compare
…rets As a part of certificates ownership work, all of new and existing secrets that are created with certificate information need to have ownership annotations. New secrets that are created with OLM certresources controller will have new ownership annotations injected at creation/update time. The existing olm-managed secrets that don't have the required annotations will get reconciled at startup when olm operator is restarted/redeployed. This PR only add OpenShift owning component annotation and the description annotation can be added later. Signed-off-by: Vu Dinh <vudinh@outlook.com>
dinhxuanvu
force-pushed
the
cert-annotations
branch
from
7eecf8c
to
98d78fe
Compare
|
@tmshort @joelanford PTAL |
|
/test e2e-gcp-olm |
| } | ||
| for _, secret := range secrets { | ||
| if secret.Annotations[install.OpenShiftComponent] == "" { | ||
| secret.Annotations[install.OpenShiftComponent] = install.OLMOwnershipAnnotation |
There was a problem hiding this comment.
I think this question applies here and in the cert generation code: Should we really say that the openshift component for every secret that OLM manages on behalf of operators is an OLM component?
Or could we properly associate the secrets we manage for the Foo operator to the Foo component?
There was a problem hiding this comment.
While I see your point, it doesn't change the fact that OLM is creating these secrets (and the certificates as well). Until OLM can delegate that responsibility to someone else, OLM effectively owns those resources from certificate ownership perspective. Also, the operators don't control these secrets. They are the consumers from that perspective. It is hardly logical for them to claim ownership on these resources that they don't have control over.
dinhxuanvu
changed the title
openshift-ci-robot
added
the
jira/valid-reference
|
@dinhxuanvu: This pull request references API-1674 which is a valid jira issue. In response to this:
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. |
|
@joelanford @tmshort Seeking for a LGTM here unless there are any further feedbacks. |
|
I can look after lunch EST |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dinhxuanvu, tmshort 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:
Approvers can indicate their approval by writing |
|
@dinhxuanvu: 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. |
|
[ART PR BUILD NOTIFIER] This PR has been included in build operator-registry-container-v4.15.0-202312042232.p0.g85c579f.assembly.stream for distgit operator-registry. |
|
[ART PR BUILD NOTIFIER] This PR has been included in build operator-lifecycle-manager-container-v4.15.0-202312042232.p0.g85c579f.assembly.stream for distgit operator-lifecycle-manager. |
As a part of certificates ownership work, all of new and existing secrets that are created with certificate information need to have ownership annotations. New secrets that are created with OLM certresources controller will have new ownership annotations injected at creation/update time. The existing olm-managed secrets that don't have the required annotations will get reconciled at startup when olm operator is restarted/redeployed. This PR only add OpenShift owning component annotation and the description annotation can be added later.
Signed-off-by: Vu Dinh vudinh@outlook.com