Closed tony closed 10 years ago
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.
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.
Salt has an API client which can probably achieve what you're after.
@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.
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.
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:
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.
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, likesalt-call --local
. (But I don't even want that, since any client entails a lot of other things)However, I notice errors when creating
salt.LocalClient
.Python API
I'm digging into the salt mine, I tried this, and I want this simplicity and pythonic power:
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, likegit.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.