Goal

• Get ORC installed as part of RHOSO deployment. We may consider making it optional at first.
• ORC respects the acceptance criteria defined in https://issues.redhat.com/browse/RHOSSTRAT-632

We are not looking to modify the different openstack operators to leverage ORC for their OpenStack resource provisioning at this stage.

Why is this important?

With the new architecture for deploying red hat openstack now coming to fruition a need came up to have a day 2 capability to orchestrate openstack resource creation across multiple openstack clouds with a simple declarative API which can be hosted on a customer designated root cluster ( RHOSO cluster0) - entering ORC - Openstack Resource controller

Scenarios

\

1. ...

Acceptance Criteria

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

Dependencies (internal and external)

Previous Work (Optional):

PoC for integrating ORC in the openstack-operator: https://github.com/openstack-k8s-operators/openstack-operator/pull/1493

Example of how to create a bundle directory for ORC: https://github.com/k-orc/openstack-resource-controller/pull/447

Open questions::

• Container images for RHOSO must support FIPS, and for this reason are still restricted to go v1.22. ORC is currently on v1.23. How do we resolve this situation? Looks like the easiest is to move ORC back to v1.22, at least for the downstream build.
• How do we promote ORC bundle to be used in the openstack-operator?
• How do we integrate with Release Delivery?