From 6f86b6e21b922e84647584a8ea7b109588c9bafa Mon Sep 17 00:00:00 2001 From: Gabriel Stein Date: Tue, 23 Apr 2024 15:55:27 +0200 Subject: [PATCH 1/3] First draft of the git integration --- ...vide-a-button-to-install-audit-packages.md | 45 +++++++++++++ accepted/00102-git-integration.md | 63 +++++++++++++++++++ 2 files changed, 108 insertions(+) create mode 100644 accepted/0000-provide-a-button-to-install-audit-packages.md create mode 100644 accepted/00102-git-integration.md diff --git a/accepted/0000-provide-a-button-to-install-audit-packages.md b/accepted/0000-provide-a-button-to-install-audit-packages.md new file mode 100644 index 00000000..22b0cc6d --- /dev/null +++ b/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? diff --git a/accepted/00102-git-integration.md b/accepted/00102-git-integration.md new file mode 100644 index 00000000..97511139 --- /dev/null +++ b/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. From 43504c0a52fe5dcf9231aa384ced9bf3adfb814d Mon Sep 17 00:00:00 2001 From: Gabriel Stein Date: Fri, 26 Apr 2024 12:36:15 +0200 Subject: [PATCH 2/3] Removes accepted/0000-provide-a-button-to-install-audit-packages.md from commit' --- ...vide-a-button-to-install-audit-packages.md | 45 ------------------- 1 file changed, 45 deletions(-) delete mode 100644 accepted/0000-provide-a-button-to-install-audit-packages.md diff --git a/accepted/0000-provide-a-button-to-install-audit-packages.md b/accepted/0000-provide-a-button-to-install-audit-packages.md deleted file mode 100644 index 22b0cc6d..00000000 --- a/accepted/0000-provide-a-button-to-install-audit-packages.md +++ /dev/null @@ -1,45 +0,0 @@ -- 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? From 9ec42d0dc9c25ca12f69caae617caa701ac68585 Mon Sep 17 00:00:00 2001 From: Gabriel Stein Date: Fri, 26 Apr 2024 13:04:17 +0200 Subject: [PATCH 3/3] Changes RFC and the file name as recommended --- accepted/00000-git-integration.md | 66 +++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 accepted/00000-git-integration.md diff --git a/accepted/00000-git-integration.md b/accepted/00000-git-integration.md new file mode 100644 index 00000000..34c8e78a --- /dev/null +++ b/accepted/00000-git-integration.md @@ -0,0 +1,66 @@ +- 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. +For all users that have multiple git repositories and branches which would like to deploy based on environment(env for ansible should be taken from the inventory file) + +- 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/collections, $local/ansible/inventory, $local/ansible/config + - Salt: $local/salt/states +- All the data would be saved in a volume which would be shared with the suma container - e.g. $provisioning +- A customer could add multiple git repositories and multiple branches - it would make easier to deploy formulas / playbooks based in a environment, like LCM do with repositories and promotion + +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(to avoid malicious formulas / playbooks into Uyuni and the linux infrastructure). + If a public repository will be accepted, it should appear a warning about it. + +# Alternatives +[alternatives]: #alternatives + +- What other designs/options have been considered? No. +- What is the impact of not doing this? In a modern approach on almost every playbook / salt state is in a git 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.