Uploaded image for project: 'Red Hat OpenStack Services on OpenShift'
  1. Red Hat OpenStack Services on OpenShift
  2. OSPRH-201

As an cloud operator, i want to be able to deploy nova with podified nova-compute agents (ironic/fake)

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done-Errata
    • Icon: Critical Critical
    • 2023Q3, rhos-18.0.0
    • None
    • nova-operator
    • None
    • enable deployment of podifed nova-compute agents with the ironic and fake virt driver.
    • False
    • Hide

      None

      Show
      None
    • False
    • OSPRH-811Red Hat OpenStack 18.0 Greenfield Deployment
    • Committed
    • Committed
    • To Do
    • OSPRH-811 - Red Hat OpenStack 18.0 Greenfield Deployment
    • nova-operator-container-1.0.0-14
    • Committed
    • Committed
    • 0% To Do, 33% In Progress, 67% Done
    • Release Note Not Required
    • Regression Only
    • 2023Q3

      This epic tracks adding support for deploying podifed nova computes per cell.
      This is scoped to the fake and ironic virt drivers only.

      The Fake driver will enable end-to-end testing of the core logic to deploy podifed compute agents and enable the groundwork to support ironic as a nova virt driver.

      Ironic integration will be the primary end-user output enabled by this work.

      Design Note:
      The CRD that models the podifed compute "NovaCompute" should have a top level driver filed to select between fake and ironic
      when set to ironic we should generate almost all the required ironic config automatically.
      internally we discussed limiting the replicas for ironic agents to 1 and only supporting multiple compute agent by having multiple NovaCompute CRs. this would be required for adoption if we want to maintain different config per host.

      the inte would be to have one NovaCompute per ironic conductor group and have only one instance instance of the nova-compute agent per conductor goup. this will disable the problematic hashring code.
      going forward we can later support the new shard key approach. https://specs.openstack.org/openstack/nova-specs/specs/2023.1/approved/ironic-shards.html

      if we are forced to supprot the peer_list we should auto generate it from the stateful set names.

              ksambor@redhat.com Kamil Sambor
              smooney@redhat.com Sean Mooney
              Jason Grosso Jason Grosso
              rhos-dfg-compute
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: