[feature request] front-end use salt modules and requires fabric / invoke / task file

[tony]

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 as fabtools (http://fabtools.readthedocs.org/en/latest/api/index.html) and states, such as fabtools.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.

from fabric.api import task
from fabtools import require

@task
def install_packages():
    require.deb.packages([
        'foo',
        'bar',
        'baz',
    ])

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:

from fabric.api import task
# http://docs.saltstack.com/en/latest/ref/states/all/salt.states.git.html#salt.states.git.latest
from salt.states import git

@task
def get_salt():
   # typing git. will may jedi autocomplete show me all the states in ``salt.states.git`` too :)
   git.latest('https://github.com/saltstack/salt.git', target='/home/tony/study/salt/salt')

$ fab get_salt

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.

[tony]

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

[tony]

Related issue from fabric project (a few years old): fabric/fabric#461

[basepi]

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 __vars__. Since we already have such easy custom modules, plus a great python client API, I'm just not sure I see the gains from trying to support fabric in this way.

[basepi]

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.

[tony]

@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. salt.module's / salt.state's aren't made in such a way to avoid race conditions with the __dunders__. Perhaps if modules / states were decoupled to work independently.

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.

[basepi]

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.