NO-JIRA: Clarify the secretref datakey structure reason

[ardaguclu]

We decided to store the SecretRef content as separate data keys in the key Secret and the encryption-config Secret, rather than using a single structured data key for each keyID.

This PR documents the rationale in the EP. So I stop forgetting it and suggesting the nested structure idea over and over again.

[openshift-ci-robot]

@ardaguclu: This pull request explicitly references no jira issue.

Details

In response to this:

We decided to carry the content of SecretRef as a separate datakey field in key Secret and encryption-config Secret instead of one structured data key per each keyID.

This PR clarifies the reason in the EP. So that I don't forget every time and propose nested structure idea every day.

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.

[ardaguclu]

/cc @p0lyn0mial @bertinatto

[openshift-ci]

@ardaguclu: all tests passed!

Full PR test history. Your PR dashboard.

Details

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.

[benluddy]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: benluddy

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [benluddy]

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