[openstack-dev] Unified Guest Agent proposal
dave at saltstack.com
Mon Dec 9 18:26:18 UTC 2013
On Mon, Dec 9, 2013 at 10:41 AM, Steven Dake <sdake at redhat.com> wrote:
> On 12/09/2013 09:41 AM, David Boucha wrote:
> On Sat, Dec 7, 2013 at 11:09 PM, Monty Taylor <mordred at inaugust.com>wrote:
>> On 12/08/2013 07:36 AM, Robert Collins wrote:
>> > On 8 December 2013 17:23, Monty Taylor <mordred at inaugust.com> wrote:
>> >> I suggested salt because we could very easily make trove and savana
>> >> salt masters (if we wanted to) just by having them import salt library
>> >> and run an api call. When they spin up nodes using heat, we could
>> >> have that to the cert exchange - and the admins of the site need not
>> >> know _anything_ about salt, puppet or chef - only about trove or
>> > Are salt masters multi-master / HA safe?
>> > E.g. if I've deployed 5 savanna API servers to handle load, and they
>> > all do this 'just import', does that work?
>> > If not, and we have to have one special one, what happens when it
>> > fails / is redeployed?
>> Yes. You can have multiple salt masters.
>> > Can salt minions affect each other? Could one pretend to be a master,
>> > or snoop requests/responses to another minion?
>> Yes and no. By default no - and this is protected by key encryption and
>> whatnot. They can affect each other if you choose to explicitly grant
>> them the ability to. That is - you can give a minion an acl to allow it
>> inject specific command requests back up into the master. We use this in
>> the infra systems to let a jenkins slave send a signal to our salt
>> system to trigger a puppet run. That's all that slave can do though -
>> send the signal that the puppet run needs to happen.
>> However - I don't think we'd really want to use that in this case, so I
>> think they answer you're looking for is no.
>> > Is salt limited: is it possible to assert that we *cannot* run
>> > arbitrary code over salt?
>> In as much as it is possible to assert that about any piece of software
>> (bugs, of course, blah blah) But the messages that salt sends to a
>> minion are "run this thing that you have a local definition for" rather
>> than "here, have some python and run it"
> Salt was originally designed to be a unified agent for a system like
> openstack. In fact, many people use it for this purpose right now.
> I discussed this with our team management and this is something
> SaltStack wants to support.
> Are there any specifics things that the salt minion lacks right now to
> support this use case?
> If I am correct of my parsing of the salt nomenclature, Salt provides a
> Master (eg a server) and minions (eg agents that connect to the salt
> server). The salt server tells the minions what to do.
That is the default setup. The salt-minion can also run in standalone mode
without a master.
> This is not desirable for a unified agent (atleast in the case of Heat).
> The bar is very very very high for introducing new *mandatory* *server*
> dependencies into OpenStack. Requiring a salt master (or a puppet master,
> etc) in my view is a non-starter for a unified guest agent proposal. Now
> if a heat user wants to use puppet, and can provide a puppet master in
> their cloud environment, that is fine, as long as it is optional.
> A guest agent should have the following properties:
> * minimal library dependency chain
Salt only has a few dependencies
* no third-party server dependencies
As mentioned above, the salt-minion can run without a salt master in
* packaged in relevant cloudy distributions
The Salt Minion is packaged for all major (and many smaller) distributions.
There is also a Windows installer.
> In terms of features:
> * run shell commands
> * install files (with selinux properties as well)
> * create users and groups (with selinux properties as well)
> * install packages via yum, apt-get, rpm, pypi
> * start and enable system services for systemd or sysvinit
> * Install and unpack source tarballs
> * run scripts
> * Allow grouping, selection, and ordering of all of the above operations
Salt-Minion excels at all the above
> Agents are a huge pain to maintain and package. It took a huge amount of
> willpower to get cloud-init standardized across the various distributions.
> We have managed to get heat-cfntools (the heat agent) into every
> distribution at this point and this was a significant amount of work. We
> don't want to keep repeating this process for each OpenStack project!
I agree. It's a lot of work. The SaltStack organization has already done
the work to package for all these distributions and maintains the packages.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev