## Problem

In the ci-framework repo, we have multiple zuul jobs defined.
Each of the zuul job have 3 stages to call the playbook during the deployment. It is pre-run, run and post-run.

We have
- multiple pre-run playbooks defined in ci/playbooks directory.
- Multiple run playbook called
- for EDPM/Baremetal jobs
- run playbook calling deploy-edpm.yaml with multiple ansible vars defined in scenario/centos-9 directory
- For content provider, kuttl and image build job
- run playbook calling their own custom playbook with multiple ansible vars defined in scenario/centos-9 directory.

CI Playbooks: https://github.com/openstack-k8s-operators/ci-framework/tree/main/ci/playbooks

Scenario files: https://github.com/openstack-k8s-operators/ci-framework/tree/main/scenarios/centos-9

deploy-edpm.yml: https://github.com/openstack-k8s-operators/ci-framework/blob/main/deploy-edpm.yml

With above architecture, we are seeing multiple problems
- so many playbooks defined in ci/playbooks directory (what does what, so confusing)
- var files stored in scenario/centos-9 directory (which are not actually scenarios)
- Repeation in scenario files

It does not give a clear picture of what scenarios we are testing and where are their setting defined. It makes harder to reproduce the job outside of CI.

Related Jira: https://issues.redhat.com/browse/OSP-25854

## Revisiting TripleO CI land

In past, we have scenarios, featureset, release, nodesets and reusable playbooks. Let's reuse the
same concept in ci-framework to solve the above problem.

Too many words:
- Scenarios: list of tht files defining how the services are getting installed
- https://github.com/openstack/tripleo-heat-templates/tree/master/ci/environments
- featureset: A file containing all the ansible vars performing a particular deployment
- https://github.com/openstack/tripleo-quickstart/tree/master/config/general_config
- release: A file containing all the ansible vars related to release
- https://github.com/openstack/tripleo-quickstart/tree/master/config/release
- nodeset: Used for ovb deployment (We might use it in future but let's see)
- https://github.com/openstack/tripleo-quickstart/tree/master/config/nodes
- playbooks: building blocking to drive the deployment
- https://github.com/openstack/tripleo-quickstart/tree/master/playbooks
- https://github.com/openstack/tripleo-quickstart-extras/tree/master/playbooks

## Let's say how we can use to solve the existing problem

Before using the above concept, Let's take an example of typical deployment.

Example Deployment:

As a developer, I want to deploy podified control plane
with 3 galera replica and network  isolation using antelope
openstack service container on openshift 4.12.
Once the deployment finishes, I want to make sure all the basic openstack
api services are functioning.

From above example:
- `podified control plane with 3 galera replica and network isolation` will be a scenario
- A CR file will represent the following scenario
- use Kustomize to customize the service
- A set of playbooks to deploy the above scenario
- `A list of ansible vars to achieve the deployment` - featureset/scenario vars
- Since the above deployment is based on `antelope openstack service container on openshift 4.12` - release file
- Since there is no mention of openshift cluster architecture let's assume it will be single node cluster - nodes

The above things has one twist:
We need to define our entrypoint just like quickstart.sh so that these things can be passed together and people
can reproduce the same locally.

## Comments