Open Stack

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 
> <mailto: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
>     <mailto: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.

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
* no third-party server dependencies
* packaged in relevant cloudy distributions

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

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!

Regards,
-steve


> -- 
> Dave Boucha  |  Sr. Engineer
>
> Join us at SaltConf, Jan. 28-30, 2014 in Salt Lake City. 
> www.saltconf.com <http://www.saltconf.com/>
>
>
> 5272 South College Drive, Suite 301 | Murray, UT 84123
> *office*801-305-3563
> dave at saltstack.com <mailto:dave at saltstack.com> | www.saltstack.com 
> <http://saltstack.com/>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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