On 12/09/2013 09:41 AM, David Boucha wrote:
On Sat, Dec 7, 2013 at 11:09 PM, Monty Taylor <mord...@inaugust.com
<mailto:mord...@inaugust.com>> wrote:
On 12/08/2013 07:36 AM, Robert Collins wrote:
> On 8 December 2013 17:23, Monty Taylor <mord...@inaugust.com
<mailto:mord...@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
d...@saltstack.com <mailto:d...@saltstack.com> | www.saltstack.com
<http://saltstack.com/>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
