CFE-544 : Apply user defined labels & tags to all GCP resources created by OpenShift

[bharath-b-rh]

PR is a design proposal to support user defined labels for the GCP resources created by Openshift. Proposal is to allow user to request for labels to be added for all the GCP resources.

[sadasu]

If the Installer is not able to apply all the userLabels during install time (), does the Installer :

1. add only the labels that were successfully added to the status.platformStatus.gcp.resourceLabels ?
2. still add ALL the userLabels to status.platformStatus.gcp.resourceLabels and the Operators later make sure to apply the other labels that the Installler was not able to add during install.

I am not sure of the conditions under which this can happen and if we should be thinking about this problem.

[bharath-b-rh]

Thank you for the comment @sadasu !!

If the Installer is not able to apply all the userLabels during install time (), does the Installer :

Installer apply labels on the resources using terraform APIs and as it's a single request operation i.e. resource creation along with the required properties including labels and should the resource creation fail for any reason including label related, installation fails. Hope the response was what you were looking for.

[bharath-b-rh]

Thank you for the comments @patrickdillon !!

[openshift-bot]

Inactive enhancement proposals go stale after 28d of inactivity.

See https://github.com/openshift/enhancements#life-cycle for details.

Mark the proposal as fresh by commenting /remove-lifecycle stale.
Stale proposals rot after an additional 7d of inactivity and eventually close.
Exclude this proposal from closing by commenting /lifecycle frozen.

If this proposal is safe to close now please do so with /close.

/lifecycle stale

[bharath-b-rh]

/remove-lifecycle stale

[bharath-b-rh]

/lifecycle frozen

[openshift-ci]

@bharath-b-rh: The lifecycle/frozen label cannot be applied to Pull Requests.

In response to this:

/lifecycle frozen

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.

[dhellmann]

@bharath-b-rh , we prefer to not have reviews stay open for a long time in this repo because it makes it less clear what designs are actually being actively worked on. If this a priority for our next release, we should work to have it reviewed and merged. If not, we should close it and reopen it when the requirement is reprioritized.

[bharath-b-rh]

@dhellmann: This has been re-prioritized for 4.13, but we were aiming to get the EP merged in 4.12. There are few points which requires clear understanding on the customer use case for which we are checking with the involved teams. Hopefully with the open points cleared, we can get the proposal merged soon.

[dhellmann]

@bharath-b-rh sounds good, thanks for those details.

[bharath-b-rh]

We received feedback from a customer, and they would like any resource created by OCP to be labelled with the user defined labels.

[bharath-b-rh]

/cc @patrickdillon @JoelSpeed @dmage

[patrickdillon]

I'm still a little confused about tags that belong to projects vs organizations. It appears to me (and please correct me if I'm wrong, because I'm figuring this out as I go): that tags can belong to either the organization OR the project; and these memberships are distinct.

So for example, using my own GCE access, I can view tags that belong to the organization:

gcloud resource-manager tags keys list --parent=organizations/54643501348
NAME                   SHORT_NAME    DESCRIPTION
tagKeys/1015955642813  ocp_tag_dev   OpenShift developers - openshift-gce-devel
tagKeys/224542852022   ServicePhase
tagKeys/719644768507   AppCode       Application Code

or a project

gcloud resource-manager tags keys list --parent=projects/openshift-gce-devel | head -n 6
NAME                     SHORT_NAME  DESCRIPTION
tagKeys/281474986956380  test24
tagKeys/281475191791652  test27
tagKeys/281475291534718  test43
tagKeys/281475640558155  test2
tagKeys/281475656997905  test26

It seems this current implementation would only support tags defined at the organization.

I think we should either:

1. Clarify that we will not support project-level tags (I would be surprised if we want to do this)
2. Add support for project-level tags. Perhaps this is as simple as making the organization field in the cluster api optional. Or we create a discriminator union in the API for organization XOR project

Again please correct me if I'm wrong/misunderstanding tags.

[bharath-b-rh]

I'm still a little confused about tags that belong to projects vs organizations. It appears to me (and please correct me if I'm wrong, because I'm figuring this out as I go): that tags can belong to either the organization OR the project; and these memberships are distinct.

Yes, tags can created at Organization or the project, provision for creating tags at project was made available only a few months back and they are distinct.

It seems this current implementation would only support tags defined at the organization.

When we started with the enhancement proposal and reached out to users as well, tags could only be created at Organization and not the project, so for TP tags defined at the Organization are only considered.

I think we should either:

1. Clarify that we will not support project-level tags (I would be surprised if we want to do this)
2. Add support for project-level tags. Perhaps this is as simple as making the organization field in the cluster api optional. Or we create a discriminator union in the API for organization XOR project

We need to make a way possible to identify the tags defined at Organization and Project, perhaps something like below or any other better ways which I think could be worked out for GA.

platform:
  gcp:
    userTags:
      <organization_id>/ocp_tag_dev: foo
      <project_id>/test1: test1

Please let me know if this is acceptable.

[patrickdillon]

We need to make a way possible to identify the tags defined at Organization and Project, perhaps something like below or any other better ways which I think could be worked out for GA.

platform:
gcp:
userTags:
<organization_id>/ocp_tag_dev: foo
<project_id>/test1: test1

Please let me know if this is acceptable.

I think this is capturing the right idea. I am happy with Joel's suggestion to make the install config mirror the API of the openshift/API. I left one comment to update the openshift/API taking into account this realization that tags can belong to projects as well as organizations: https://github.com/openshift/enhancements/pull/1217/files#r1260103854

[patrickdillon]

/lgtm

[JoelSpeed]

/lgtm

/assign @jerpeter1

@jerpeter1 I think ever other requested reviewer has LGTM'd this now

[jerpeter1]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jerpeter1

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

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

[openshift-ci]

@bharath-b-rh: 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.