Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
makentenza opened this issue Jun 9, 2020 · 3 comments
Open

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

makentenza opened this issue Jun 9, 2020 · 3 comments

Comments

@makentenza
Copy link
Contributor

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
Copy link
Collaborator

fridim commented Jul 2, 2020

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
Copy link
Collaborator

tonykay commented Jul 2, 2020

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
Copy link
Contributor Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants