Using salt as pure, surgical, local, minion-less, import n' go, python lib.

[tony]

Carried on from #7242 and earlier #3945

I want salt usable as a pure library. 0 config.

Only care about core grains, modules and states.

Situation: making a python app to manage VCS states via a simple config. Salt states allow me to do this in a clean, cross-platform way.

If this works: Salt's current modules and states can be usable as cross-platform pythonic objects to interface with system states and commands. Examples: fabtools: http://fabtools.readthedocs.org/en/0.15.0/api/require/index.html, saltstack: http://docs.saltstack.com/ref/states/all/.

Am I looking in the wrong place?

My first guess is salt.LocalClient may get me "minion-less", 0 config python access, like salt-call --local. (But I don't even want that, since any client entails a lot of other things)

import salt.client

client = salt.LocalClient()
ret = client.cmd('*', 'cmd.run', ['whoami'])

However, I notice errors when creating salt.LocalClient.

SaltClientError: Could not access /var/cache/salt. Please give tony read permissions.

Python API

I'm digging into the salt mine, I tried this, and I want this simplicity and pythonic power:

import salt.modules.git

ret = git.clone('/home/tony', 'https://github.com/saltstack/salt.git')

>>> NameError: global name '__salt__' is not defined

http://docs.saltstack.com/ref/modules/#cross-calling-modules

https://github.com/saltstack/salt/blob/develop/salt/loader.py#L357

I now see that some sort of a new client or bootstrap process may be needed to assure __salt__ works.

As it stands, I'm digging through the source trying to find a way :) Pointers will be rewarded with greatness.

Salt grains, modules, states work out of box in python

For fun and profit. I think its possible and can open new doors.

I want client / python API to be able to utilize modules, states and grains out of the box with no configuration. I'm not concerned about async, caching, top files, requirements, file roots, pillars. I want to be able to enter a dict of a state, like git.latest into salt and have it work on the local machine.

Where does this stand in the state of salt? I don't really want a minion or a master, I want to programmatically run my states and handle it at that level.

[s0undt3ch]

Those variables are defined when salt loads the module. It's not meant to be used like that, ie, they are not importable from outside salt.

Pedro Algarvio @ phone

----- Reply message ----- De: "Tony Narlock" notifications@github.com Para: "saltstack/salt" salt@noreply.github.com Assunto: [salt] salt.LocalClient, salt-thin - Can salt work as a pure library? (#8587) Data: sáb, Nov 16, 2013 10:00 I'm digging, I tried this:

import salt.modules.git

git.clone('/home/tony', 'https://github.com/saltstack/salt.git')

NameError: global name 'salt' is not defined

http://docs.saltstack.com/ref/modules/#cross-calling-modules

Where is salt created in the code?

— Reply to this email directly or view it on GitHub.

[tony]

This runs contrary to where salt is heading. State configurations, cloud management, etc. I see the great minds here focused on scaling, however there is a niche here and it just may be big enough to earn attention.

Access to grains, modules and states on a clientless, python level can be helpful for reasons stated above and for testing purposes on grains, modules and states.

As for this issue, I don't think this is going to go anywhere unless there is a PR. It's good to make sure the idea is out there and articulated.

[s0undt3ch]

Salt has an API client which can probably achieve what you're after.

http://docs.saltstack.com/ref/clients/index.html

[tony]

@s0undt3ch

Not quite, these require a config, /var/salt/cache and a minion. I discussed this more in the top issue (but I edited a few times, so it probably didn't show up in email)

I have a hunch, grains, modules and states, because of the way they are architectured, can be used as-is without minion, config or bootstapping. It could just pass through into python subprocess and return the output.

I think we're paving a way in that direction even if it's accidental. @thatch45's https://github.com/saltstack/salt-thin has something that gets a bit closer, and recent commits to salt in the past month or two fixed a lot dependency issues we had in the way with zmq/crypt.

7242 and earlier #3945 discuss keeping modules and states decoupled enough not to require a client.

I want to try to poke around the code more and wrap my brain around Loader.py, modules and states. It's really great to watch this project grow.

[tony]

Edited the above post, please don't rely on my issue responses by email if you can help it, I edit a lot after my posts. :smiley:

[basepi]

The file cache is very important to salt (without it, a lot of the modules will work, but nothing file-related). I think that's really the only thing standing in the way of what you want to do. The caching location is configurable (via the root_dir config option -- we're back to config). It's designed so that you can use it from within a virtualenv, for example. But all of this portability and versatility requires configuration. Either you have to redefine the defaults within salt/config.py or you have to pass in the location of a config file. Not sure there's a way around that. Salt is designed to be very versatile, but it's not designed to be able to split up into separate working components. Too much interconnection.