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

OpenStackServer controller in CAPO

XMLWordPrintable

    • OpenStackServer controller in CAPO
    • False
    • None
    • False
    • Not Selected
    • To Do
    • OCPSTRAT-1381 - Feature - OpenStackServer controller in CAPO
    • 0% To Do, 60% In Progress, 40% Done

      Goal

      CAPO uses a function named CreateInstance to create OpenStack servers and it's been used by the machine controller for OpenStackMachine, the cluster controller for the bastion and OpenShift's Machine API Provider OpenStack.

      Of these, the bastion has been most problematic. The principal current problem with the bastion is that, unlike OpenStackMachine, it is mutable because the bastion is not required to have the same lifecycle as the cluster which contains it.
      The current API allows the user to modify the bastion, and the controller is expected to delete the current one and create a new one. This is a problem in edge cases where the spec is required to determine if resources were previously created and need to be cleaned up, or not. This is a fundamental design problem, but another less fundamental but still very real problem is that trying to integrate the bastion into both the cluster and (effectively) machine creation and deletion flows creates fragile code and has resulted in numerous bugs.

      The goal of this EPIC is to create a new controller which is capable, in principal, of doing all of the OpenStack resource creation tasks common to bastion and the OpenStackMachine creation.

      Why is this important?

      • Contributes to CAPO stability in the long term.
      • Makes Shift on Stack more robust.
      • Facilitates the migration from MAPI to CAPI at some point, if we find a way for MAPO to use that new controller/object.

      Scenarios

      1. Bastion in OpenStackCluster: unlike OpenStackMachine, the bastion is mutable and can have the same lifecycle as the cluster which contains it. The current API allows the user to modify the bastion, and the controller is expected to delete the current one and create a new one.
      1. OpenStackMachine: this object is immutable and creates the instance once.
      1. MAPO: this might be out of scope for 4.17 but will probably become something useful during the 4.19 cycle with the CAPI operator being GA.

      Acceptance Criteria

      • Patches merged upstream.
      • In the case of MAPO not using the new controller, MAPO can still use the *CreateInstance* function.
      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement

      Dependencies (internal and external)

      1. CAPO - the proposal has to be approved.

      Previous Work (Optional):

      1. PoC: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/pull/2067

      Open questions::

      1. none

            emacchi@redhat.com Emilien Macchi
            emacchi@redhat.com Emilien Macchi
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: