First draft of the git integration

accepted/0000-provide-a-button-to-install-audit-packages.md

@@ -0,0 +1,45 @@
+- Feature Name: (fill with a unique ident, my_awesome_feature)
+- Start Date: (fill with today's date, YYYY-MM-DD)
+
+# Summary
+[summary]: #summary
+
+Brief (one-paragraph) explanation of the feature.
+
+# Motivation
+[motivation]: #motivation
+
+- Why are we doing this?
+- What use cases does it support?
+- What is the expected outcome?
+
+Describe the problem you are trying to solve, and its constraints, without coupling them too closely to the solution you have in mind. If this RFC is not accepted, the motivation can be used to develop alternative solutions.
+
+# Detailed design
+[design]: #detailed-design
+
+This is the bulk of the RFC. Explain the design in enough detail for somebody familiar with the product to understand, and for somebody familiar with the internals to implement.
+
+This section should cover architecture aspects and the rationale behind disruptive technical decisions (when applicable), as well as corner-cases and warnings. Whenever the new feature creates new user interactions, this section should include examples of how the feature will be used.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+Why should we **not** do this?
+
+  * obscure corner cases
+  * will it impact performance?
+  * what other parts of the product will be affected?
+  * will the solution be hard to maintain in the future?
+
+# Alternatives
+[alternatives]: #alternatives
+
+- What other designs/options have been considered?
+- What is the impact of not doing this?
+
+# Unresolved questions
+[unresolved]: #unresolved-questions
+
+- What are the unknowns?
+- What can happen if Murphy's law holds true?

accepted/00102-git-integration.md

@@ -0,0 +1,63 @@
+- Feature Name: Git integration
+- Start Date: 2024-04-23
+
+# Summary
+[summary]: #summary
+
+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
+[motivation]: #motivation
+
+- Why are we doing this?
+The git integration is not existent or it the depends from gitfs which is unstable
+
+- What use cases does it support?
+For all users which have a lot of self-written salt formulas and ansible-playbooks.
+
+- What is the expected outcome?
+Use salt formulas and ansible playbooks which are stored on git repositories
+Use them against clients managed by Uyuni
+
+
+# Detailed design
+[design]: #detailed-design
+
+It should be designed on four parts:
+
+The first part would be done by a container that is responsible to sync the git repositories and sort it out per type of the provisioning tool.
+ - 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
+   - 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.
+
+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.
+
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+Why should we **not** do this?
+
+  * 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.
+
+# Alternatives
+[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
+
+# Unresolved questions
+[unresolved]: #unresolved-questions
+
+- What are the unknowns?
+- What can happen if Murphy's law holds true? Deactivate the module and fix it.