Introduce "adoption" snippet in automation file #382
Conversation
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cjeanner The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This playbook allows to create an infrastructure, mostly related to the "adoption" use-case. It allows to consume overrides provided by the automation file shipped within the architecture repository. This, alongside openstack-k8s-operators/architecture#382, allows to create an infrastructure suitable for adoption testing.
cjeanner
force-pushed
the
adoption/infra_playbook
branch
2 times, most recently
from
5a0705d
to
c34be3e
Compare
This playbook allows to create an infrastructure, mostly related to the "adoption" use-case. It allows to consume overrides provided by the automation file shipped within the architecture repository. This, alongside openstack-k8s-operators/architecture#382, allows to create an infrastructure suitable for adoption testing.
This playbook allows to create an infrastructure, mostly related to the "adoption" use-case. It allows to consume overrides provided by the automation file shipped within the architecture repository. This, alongside openstack-k8s-operators/architecture#382, allows to create an infrastructure suitable for adoption testing.
cjeanner
force-pushed
the
adoption/infra_playbook
branch
from
c34be3e
to
ff01627
Compare
This playbook allows to create an infrastructure, mostly related to the "adoption" use-case. It allows to consume overrides provided by the automation file shipped within the architecture repository. This, alongside openstack-k8s-operators/architecture#382, allows to create an infrastructure suitable for adoption testing.
cjeanner
force-pushed
the
adoption/infra_playbook
branch
from
ff01627
to
ae6968d
Compare
#375 splits the default vars into different scenario files. openstack-k8s-operators/ci-framework#2267 suggests to use Use cifmw_architecture_scenario to set proper automation file. So we are no longer needing default.yaml file. Depends-On: openstack-k8s-operators/ci-framework#2267 Signed-off-by: Chandan Kumar (raukadah) <raukadah@gmail.com>
cjeanner
force-pushed
the
adoption/infra_playbook
branch
2 times, most recently
from
36860a8
to
02b880c
Compare
cjeanner
changed the title
For adoption, there's a need to override the infra exposed by the scenario. While this new "adoption" entry creates a stronger link with the ci-framework, it can also be consumed by any other tool, as long as it knows how to consume the two "patches". This is part of a PoC, and will probably lead to discussions regarding the best way to manage all of the datasets.
cjeanner
force-pushed
the
adoption/infra_playbook
branch
from
02b880c
to
d41972e
Compare
| amount: 0 | ||
| osp-undercloud: | ||
| amount: 1 | ||
| disk_file_name: rhel-8.10.qcow2 |
There was a problem hiding this comment.
I'm wondering if we want this level of detail in architecture, where we're defining a bunch of VMs settings.
I would have expected to have this kind of definition in ci-framework (like we do for greenfield, right?) and reference a "scenario" that can be loaded in terms of specific parameters.
However, I'm not saying this is a bad approach, as we have a clear view of the infra associated to VA1 in the adoption context in architectures.
I'll let @marios @jistr @cescgina comment further on this.
There was a problem hiding this comment.
we can. It could point to a thing to inherit from, but there are some caveats there, like the file location (remote vs ansible-controller). Indeed, this proposal here might link a bit too much to the framework, while having a file pointer could do.
And if we go down that path, we can push everything in that file - leading to this automation, in architecture, to have "just" adoption: relative/path/to/scenario.yml
But there would still be the "where to store t-h-t static/dynamic content that needs to be injected"... And there, I'm sure it doesn't belong to the ci-framework. Probably "bad" for architecture. But I'm not sure if there would be any other "good" place :/
There was a problem hiding this comment.
I think that a VA/DT already defines a set of services and it can be used as source of truth to define a static set of THT env files. That part is not "strictly" connected to the infra IMO, and it might live here in terms of "description" of the source cloud.
WRT the infra part, we could minimize the changes here by referencing a scenario that lives in the adoption ci-framework path, but I'd like to hear more opinions.
My comment started from the assumption that for greenfield VA/DTs we have scenario files that live in ci-framework, and we might want to be consistent with the already existing approach.
There was a problem hiding this comment.
What if this infra style change to hci.yaml were in ci-framework/scenarios/adoption/hci.yaml?
Then in architecture/automation/vars/hci.yaml it could have a reference to ci-framework/scenarios/adoption/hci.yaml?
There was a problem hiding this comment.
we could, indeed. We'd even NOT need any reference from any file: the scenario name, and the fact it's "adoption" should be sufficient to built the pointer to the file.
It won't solve the "where do we put OSP t-h-t content", but it reduces the amount of affected repositories in case of changes. I didn't think about it, and I'm ashamed of that ;_;.
Far, far cleaner to pass via scenario files - and that's the purpose if them anyway!
| # Adoption related content for adoption | ||
| adoption: | ||
| hci: | ||
| layout_patch: |
There was a problem hiding this comment.
Just diving a bit deeper into CI framework (this is my first real encounter with it).
If this is patching cifmw_libvirt_manager_layout then should we name the patch variables accordingly? Like cifmw_libvirt_manager_layout_patch? I wouldn't be afraid of long names for the sake of clarity.
Also where does the actual cifmw_libvirt_manager_layout value come from for the architecture jobs? I was wondering about the patching approach in general, vs. just redefining the variable for adoption, but i can't find the variable for greenfield here in this repo or in ci-framework. Is there another repo i should be looking at?
There was a problem hiding this comment.
FWIW i was looking at https://github.com/openstack-k8s-operators/ci-framework/pull/2285/files#diff-8599ae825f8eabc23397e4f5dd09e71bd037657b1f3e837565cb162d245b3a1cR93 . I guess _cifmw_libvirt_manager_layout there gets processed from cifmw_libvirt_manager_configuration? https://github.com/openstack-k8s-operators/ci-framework/blob/b349f2735319daea1d1b43cb6b14cd7af4fa16db/scenarios/reproducers/va-hci.yml#L21
There was a problem hiding this comment.
The patching is done here:
https://github.com/openstack-k8s-operators/ci-framework/blob/main/roles/libvirt_manager/tasks/generate_layout.yml
patches are nice, since we don't need to redefine the whole thing. There's one weakness though : we can't delete any entry.
The playbooks I proposed in openstack-k8s-operators/ci-framework#2285 are taking care of the dataset manipulation/patching
|
Closing this PR, since we can now rely on the ci-framework scenario nested in You can check openstack-k8s-operators/ci-framework#2285 to follow the evolution. |
For adoption, there's a need to override the infra exposed by the
scenario.
While this new "adoption" entry creates a stronger link with the
ci-framework, it can also be consumed by any other tool, as long as it
knows how to consume the two "patches".
This is part of a PoC, and will probably lead to discussions regarding
the best way to manage all of the datasets.