Closed chrismoos closed 7 years ago
Conflicting ad-hoc approaches to dependency management is suboptimal: if X and Y depend upon Z being installed and configured and manage that dependency themselves, the order of operations determines which e.g. configuration file "wins" (remains on disk after the additive combinations of transformations are applied)
Generally, it's not a safe assumption that - to reference the aforementioned example - both X and Y have utilized idempotent strategies for configuration management, so running both X and Y in any order an arbitrary number of times does not result in the desired outcome. For example, if X replaces httpd.conf and Y simply tries to append a configuration section, the end result is not consistent unless: (1) the execution order is consistent; and (2) Y is only run one time. https://en..wikipedia.org/wiki/Idempotence
More abstract dependency management could avoid applying multiple conflicting formulas (if it were possible to express that X and Y depend upon an abstract requirement Z, which e.g. Z-org-formula provides)
Abstract dependencies are kicking the can down the road, not problem solving.
People will do it wrong, and the problems that result from well intentioned misunderstandings will be worse than the problems of fixing broken concrete dependencies.
https://twitter.com/Spearhafoc_/status/1028239907628740608?s=20
https://docs.saltstack.com/en/latest/topics/spm/spm_formula.html#dependencies
On Sat, Jul 18, 2020, 7:04 PM Jeremy McMillan notifications@github.com wrote:
Abstract dependencies are kicking the can down the road, not problem solving.
People will do it wrong, and the problems that result from well intentioned misunderstandings will be worse than the problems of fixing broken concrete dependencies.
https://twitter.com/Spearhafoc_/status/1028239907628740608?s=20
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/saltstack/salt/issues/12179#issuecomment-660554869, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMNSZWBXN5QXQ4RWMUASLR4IS6BANCNFSM4AORF7BA .
I think there should be a standard way to manage formula dependencies. It is very natural for a state to be composed of other states but when using third party formula there is no easy way to manage the dependencies, versions, etc,.
A popular tool for Chef is Berkshelf. You put a file in your cookbook root (or state tree root in Salt's case) like this:
There is a CLI command so you can fetch and install all of the dependencies, for example.
I propose we do the same thing for Salt's formula:
Saltfile - This will contain the dependencies, sources, etc,. Saltfile.lock - This will contain all of the active/installed dependencies and their versions.
There will be a tool that will fetch and install the dependences, just like the berkshelf command.
I think that having this feature is really important especially as your state tree gets more advanced and you start pulling in third party formula.
Example Saltfile: