Open Stack

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
>> into
>> >> 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
>> easily
>> >> 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
>> savana.
>> >
>> > 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"
>>
>> Monty
>>
>>
>
>  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?
>
>
> David,
>
> 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
standalone mode

 * packaged in relevant cloudy distributions
>

The Salt Minion is packaged for all major (and many smaller) distributions.
RHEL/EPEL/Debian/Ubuntu/Gentoo/FreeBSD/Arch/MacOS
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.


>
> Regards,
> -steve
>
>
>

Regards,

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131209/2dd2118f/attachment.html>