-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
[feature request] front-end use salt modules and requires fabric / invoke / task file #22842
Comments
Proof of concept salt vanilla states / modules can work in pure python: https://gist.github.com/tony/6d8d975c817d2e4d43dd#file-salt_python-py Salt modules / states fabfile remote execution: https://gist.github.com/tony/6d8d975c817d2e4d43dd#file-fabfile-py |
Related issue from fabric project (a few years old): fabric/fabric#461 |
This seems like it might just be a job for custom modules. They allow you to use all the power of salt very pythonically. More information in the docs and from my SaltConf15 talk. There's also a Python client API which could be useful. But making salt modules easily accessible in the way you've shown in fabric would be very difficult, because these modules rely on other information provided by the minion: grains information, pillar information, minion opts, and the other execution module functions, all injected automatically into special |
tl;dr: Salt's execution modules expect to be processed by the loader. If you wanted to try to wrap the loader in fabric to gain access to these modules, go for it, but I don't think we'll support this officially. |
@basepi : Thank you for wrapping your brain around what I'm trying to say, I want to make the point clear. I looked at this. Ultimately, I through my hands up and went back to writing salt states. It's nice to have a proof of concept out there and know we touched the issue. If anyone else happens to have desire / input on this in either direction, we can hear it here. |
Yeah, it would be nice if we could make this work easily. I guess it was just not meant to be. I'm going to close this for now, but it will be here for future reference and discussion. |
From #8587.
My use case still exists. Even with salt, I have a huge void, because there are many projects I have where building and maintaining salt configs isn't worth it - or my fellow team members may not be familiar with salt. Also, tasks are more amenable to the circumstances.
They're not managing configs in a classical sense, they're running tasks pythonically, use a tool that has become very common in the community because of it's simplicity - it's called fabric. The benefit from building a repo of
sls
and setting up a fully-fledged salt system isn't there. However, their team would prosper from fabric's familiarity, small learning-curve, salt's ability to connect to a server, detect it's environment and act on salt's huge repository of salt modules / requirements. In addition, being able to natively import the module / require objects as they are in salt's documentation would be a colossal win.There are already projects trying to extend fabric's functionality to imitate
modules
, such asfabtools
(http://fabtools.readthedocs.org/en/latest/api/index.html) andstate
s, such asfabtools.require
(http://fabtools.readthedocs.org/en/latest/api/require/). However, it doesn't cover anywhere near the cases that salt's states could. Further it doesn't have salt's ability to detect and act on the system's environmental conditions.I want to be able to use salt.modules.git like fabtools.git and salt.states.git like fabtools.require.git.
The salt equivalent would be:
Is their anyone else out there that has a desire / use case for being able to use salt modules / states pythonically, just like fabfile? No master, no minions, no pillars, no renderers. Purely with the front-end config style fabric uses.
I think it's interesting. It could be an catalyst to salt to many who are wary of adopting, or learning a new configuration management system. When and if their needs because complex enough to warrant a full-fledged salt config for their project, they'll already have learned and become accustomed to the convenience of modules / states. So the second reason I like this, aside from it handling a huge gap I find on so many projects, is it could bring the benefits salt to more people, without having to change patterns they're already accustomed to.
The text was updated successfully, but these errors were encountered: