Uploaded image for project: 'OpenShift Top Level Product Strategy'
  1. OpenShift Top Level Product Strategy
  2. OCPPLAN-8154

Apply user defined tags to all resources created by OpenShift (AWS)

XMLWordPrintable

    • False
    • False
    • ?
    • No
    • ?
    • ?
    • ?
    • 0% To Do, 0% In Progress, 100% Done

      Feature Overview

      The AWS-specific code added in OCPPLAN-6006 needs to become GA and with this we want to introduce a couple of Day2 improvements.
      Currently the AWS tags are defined and applied at installation time only and saved in the infrastructure CRD's status field for further operator use, which in turn just add the tags during creation.

      Saving in the status field means it's not included in Velero backups, which is a crucial feature for customers and Day2.
      Thus the status.resourceTags field should be deprecated in favour of a newly created spec.resourceTags with the same content. The installer should only populate the spec, consumers of the infrastructure CRD must favour the spec over the status definition if both are supplied, otherwise the status should be honored and a warning shall be issued.

      Being part of the spec, the behaviour should also tag existing resources that do not have the tags yet and once the tags in the infrastructure CRD are changed all the AWS resources should be updated accordingly.

      On AWS this can be done without re-creating any resources (the behaviour is basically an upsert by tag key) and is possible without service interruption as it is a metadata operation.

      Tag deletes continue to be out of scope, as the customer can still have custom tags applied to the resources that we do not want to delete.

      Due to the ongoing intree/out of tree split on the cloud and CSI providers, this should not apply to clusters with intree providers (!= "external").

      Once confident we have all components updated, we should introduce an end2end test that makes sure we never create resources that are untagged.

      After that, we can remove the experimental flag and make this a GA feature.

      Goals

      • Inclusion in the cluster backups
      • Flexibility of changing tags during cluster lifetime, without recreating the whole cluster

      Requirements

      • This Section:* A list of specific needs or objectives that a Feature must deliver to satisfy the Feature.. Some requirements will be flagged as MVP. If an MVP gets shifted, the feature shifts. If a non MVP requirement slips, it does not shift the feature.
      Requirement Notes isMvp?
      CI - MUST be running successfully with test automation This is a requirement for ALL features. YES
      Release Technical Enablement Provide necessary release enablement details and documents. YES

      List any affected packages or components.

      • Installer
      • Cluster Infrastructure
      • Storage
      • Node
      • NetworkEdge
      • Internal Registry
      • CCO

            heheffne@redhat.com Heather Heffner
            heheffne@redhat.com Heather Heffner
            Votes:
            2 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: