First draft of the git integration #90
Conversation
There was a problem hiding this comment.
This file shouldn't be part of your PR, only accepted/00102-git-integration.md
| - If that is a ansible playbook it would be scanned(find $path for a role infrastructure) | ||
| - If that is a salt formula it should be done by the states delivered by the repository | ||
| - Path structure: | ||
| - Ansible: $local/ansible/roles, $local/ansible/inventory, $local/ansible/config |
There was a problem hiding this comment.
should also cover collections? $local/ansible/collections
| - If that is a salt formula it should be done by the states delivered by the repository | ||
| - Path structure: | ||
| - Ansible: $local/ansible/roles, $local/ansible/inventory, $local/ansible/config | ||
| - Salt: $local/salt/states, $local/ansible/config |
There was a problem hiding this comment.
Why would someone have a ansible config in a salt formula repo?
| - Salt: $local/salt/states, $local/ansible/config | ||
| - All the data would be saved in a volume which would be shared with the suma container - e.g. $provisioning | ||
|
|
||
| The second part it would be done for a md5/sha256sum check. If possible, also a scan that could be done for a container with e.g. clamav to check if there any viroses / trojans being imported into the clients being managed by Uyuni. |
There was a problem hiding this comment.
The checksum part sounds like a good candidate to add (optional) ansible-sign support: https://ansible.readthedocs.io/projects/sign/en/latest/.
Not sure about the clamav part though. This seems uncommon when synching repo content.
|
|
||
| The third part will be dependent from the the first two parts. If everything runs right that would be processed either by the salt master from Uyuni or the ansible control node - so here will probably smart to get rid of the manual configuration from the ansible playbooks and inventories and parse the configuration which will be delivered by the shared volume. | ||
|
|
||
| The fourth part would be a normalization from this content from the user and commit it to a different repository that would be used by Uyuni. The motivation here is to have a standard path infrastructure that makes easy the onboarding on Uyuni. |
There was a problem hiding this comment.
I know it's not Uyuni's goal to be an AWX clone. But to be honest, this problem was already kind of solved so the logic how to sync from git could follow a similar approach as described in https://ansible.readthedocs.io/projects/awx/en/latest/userguide/projects.html#scm-types-git-and-subversion
| * obscure corner cases - Users which do not have any qualíty control on their provisioning tools, importing from malicious playbooks / states from a public git repository | ||
| * will it impact performance? No, it will accelerate the adoption from Uyuni for users with and existent provisioning structure | ||
| * what other parts of the product will be affected? Salt-Master | ||
| * will the solution be hard to maintain in the future? No, it would not. It should be delivered as a module that anytime could be activated. If the customer does not have nothing in a git repository he will not activate this feature. It also not be possible to activate without git(github, gitlab....),git_repo, branch and auth_details. Public repositories on github will not be accepted as a security measure. |
There was a problem hiding this comment.
Public repositories on github will not be accepted as a security measure. disagree with that. There is no reason to force customers to authenticate against a private repo. Public repositories are fine and a valid use-case.
| # Alternatives | ||
| [alternatives]: #alternatives | ||
|
|
||
| - What other designs/options have been considered? No. |
There was a problem hiding this comment.
I would say, there are not much other options to consider in this specific case. The idea is to allow customers to manage salt formulas / ansible playbooks in git repositories that are then used by Uyuni. Implementation details can be further fleshed out but the overall idea is pretty straight forward.
| [alternatives]: #alternatives | ||
|
|
||
| - What other designs/options have been considered? No. | ||
| - What is the impact of not doing this? It will make more difficult for teams to adopt the product - in a modern approach on almost everym playbook / salt state is in a private repository and the automation is needed to manage tons of linux clients |
There was a problem hiding this comment.
Probably not, they would likely continue to use the other Uyuni features but keep the Automation part separate from it. So the proposed feature will drive adoption of Uyuni for Automation tasks, but unlikely that someone decide to use Uyuni only because of this. It's not a black/white thing.
|
|
||
| This is a feature which will add a git integration to Uyuni without the need to use gitfs. It would be possible to sync formulas and playbooks and use them with an existent infrastructure. | ||
|
|
||
| # Motivation |
There was a problem hiding this comment.
I also think it would play nicely with EDA (uyuni-project/uyuni#7801)
| Use them against clients managed by Uyuni | ||
|
|
||
|
|
||
| # Detailed design |
There was a problem hiding this comment.
What I think is missing: Such a solution should include that customers can add N git repositories. It is pretty unlikely that everything is in one large mono-repo.
This is a first draft to integrate a git repository full of ansible playbooks / salt states into Uyuni.