Uploaded image for project: 'OpenStack as Infra'
  1. OpenStack as Infra
  2. OSASINFRA-3207

Integrate CAPO into cluster-capi-operator (TP)

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Major Major
    • openshift-4.15
    • None
    • None
    • None
    • CAPO in cluster-capi-operator
    • False
    • None
    • False
    • Not Selected
    • To Do
    • OCPSTRAT-1058 - Integrate CAPO into cluster-capi-operator (TP)
    • 100
    • 100% 100%
    • Hide
      The Cluster API Provider for OpenStack (CAPO) is now deployed by default when the {{TechPreviewNoUpgrade}} feature flag is enabled. The lifecycle of this component is managed by the Cluster CAPI Operator. When the {{TechPreviewNoUpgrade}} feature flag is enabled, a {{Cluster}} and {{OpenStackCluster}} will be created automatically for the current OpenShift cluster. It is now possible to configure CAPI {{Machine}}, and {{OpenStackMachine}} resources in similar fashion to how MAPI resources are configured. It is important to note, however, that these resources are equivalent but not identical. It may also be possible to create other CAPI resource types, but this is not tested at this time.
      Show
      The Cluster API Provider for OpenStack (CAPO) is now deployed by default when the {{TechPreviewNoUpgrade}} feature flag is enabled. The lifecycle of this component is managed by the Cluster CAPI Operator. When the {{TechPreviewNoUpgrade}} feature flag is enabled, a {{Cluster}} and {{OpenStackCluster}} will be created automatically for the current OpenShift cluster. It is now possible to configure CAPI {{Machine}}, and {{OpenStackMachine}} resources in similar fashion to how MAPI resources are configured. It is important to note, however, that these resources are equivalent but not identical. It may also be possible to create other CAPI resource types, but this is not tested at this time.
    • Technology Preview

      Goal

      • Ensure that CAPO can be deployed by cluster-capi-operator

      Why is this important?

      • CAPI support is considered strategic in OpenShift
      • CAPI has a larger feature set than MAO
      • CAPO has a larger feature set than MAPO
      • CAPO is better tested that MAPO
      • cluster-capi-operator integration gives us an avenue to remove most of the remaining custom code from MAPO

      Scenarios

      1. A user should be able to create a set of workers with a MachineDeployment
      2. Users benefit from features and bugfixes in upstream CAPO with minimal release delay

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement
      • ...

      Dependencies (internal and external)

      1. cluster-capi-operator is currently being redesigned
      2. CAPO needs to publish a v1beta1 API

      Previous Work (Optional):

      1. ...

      Open questions::

      1. ...

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Technical Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

            rhn-gps-mbooth Matthew Booth
            rhn-gps-mbooth Matthew Booth
            Emilien Macchi, Pierre Prinetti, Stephen Finucane
            Jon Thomas Jon Thomas
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: