search

redhat-cop / agnosticd

AgnosticD - Ansible Deployer for multiple Cloud Deployers
https://redhat-cop.github.io/agnosticd/
GNU General Public License v3.0
384 stars 491 forks source link

Decouple AgnosticD 'core' from AgnosticD 'configs' in AgnosticV #1887

Open makentenza opened 4 years ago

makentenza commented 4 years ago

Is your feature request related to a problem? Please describe. Right now we are using the same commit while deploying any lab to clone the AgnosticD 'core' components and users 'configs'. For reliability, we create tags to ensure the configuration is working at some stage, but if this code needs to be updated later we need to commit on top of that tag not being able to incorporate any AgnosticD core functionalities unless you do a complex manual merge on your own branch from that tag

Describe the solution you'd like While using AgnosticV to pull the core and config code from AgnosticD, I'd like to be able to specify different branches or tags for each component.

Describe alternatives you've considered Move all the config code out from AgnosticD to specific roles, which is not ideal for every single task on the config as these roles will be completely related in many cases on how AgnosticD implements the Infra and Workload automation

Additional context No additional context.

fridim commented 4 years ago

This could be achieved in the deployer scripts. We could download the 'core' at a specific revision, and the "dynamic" config at another before running ansible-playbook.

@tonykay would that be possible in dark tower ?

tonykay commented 4 years ago

Not without some or even a lot of hackery @fridim - but doesn't this make life even more complex? IMHO if this is the direction then you are better off with 2 repos? And/Or the joy of git submodules. @jkupferer what are your thoughts?

makentenza commented 4 years ago

There are a lot of moving pieces already, and all under the same repo (core, configs, roles, workloads....etc) will make things more complicated going forward IMHO. I think submodules is a good approach @tonykay, maybe something to take in consideration?