<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 9, 2013 at 10:41 AM, Steven Dake <span dir="ltr"><<a href="mailto:sdake@redhat.com" target="_blank" class="ci-email">sdake@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div>
<div>On 12/09/2013 09:41 AM, David Boucha
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Sat, Dec 7, 2013 at 11:09 PM,
Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank" class="ci-email ci-contact">mordred@inaugust.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
<br>
On 12/08/2013 07:36 AM, Robert Collins wrote:<br>
> On 8 December 2013 17:23, Monty Taylor <<a href="mailto:mordred@inaugust.com" target="_blank" class="ci-email ci-contact">mordred@inaugust.com</a>>
wrote:<br>
>><br>
><br>
>> I suggested salt because we could very easily
make trove and savana into<br>
>> salt masters (if we wanted to) just by having
them import salt library<br>
>> and run an api call. When they spin up nodes
using heat, we could easily<br>
>> have that to the cert exchange - and the admins
of the site need not<br>
>> know _anything_ about salt, puppet or chef -
only about trove or savana.<br>
><br>
> Are salt masters multi-master / HA safe?<br>
><br>
> E.g. if I've deployed 5 savanna API servers to
handle load, and they<br>
> all do this 'just import', does that work?<br>
><br>
> If not, and we have to have one special one, what
happens when it<br>
> fails / is redeployed?<br>
<br>
</div>
Yes. You can have multiple salt masters.<br>
<div><br>
> Can salt minions affect each other? Could one
pretend to be a master,<br>
> or snoop requests/responses to another minion?<br>
<br>
</div>
Yes and no. By default no - and this is protected by key
encryption and<br>
whatnot. They can affect each other if you choose to
explicitly grant<br>
them the ability to. That is - you can give a minion an
acl to allow it<br>
inject specific command requests back up into the master.
We use this in<br>
the infra systems to let a jenkins slave send a signal to
our salt<br>
system to trigger a puppet run. That's all that slave can
do though -<br>
send the signal that the puppet run needs to happen.<br>
<br>
However - I don't think we'd really want to use that in
this case, so I<br>
think they answer you're looking for is no.<br>
<div><br>
> Is salt limited: is it possible to assert that we
*cannot* run<br>
> arbitrary code over salt?<br>
<br>
</div>
In as much as it is possible to assert that about any
piece of software<br>
(bugs, of course, blah blah) But the messages that salt
sends to a<br>
minion are "run this thing that you have a local
definition for" rather<br>
than "here, have some python and run it"<br>
<span><font color="#888888"><br>
Monty<br>
</font></span>
<div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div><span style="font-family:arial,sans-serif;font-size:13px">Salt
was originally designed to be a unified agent for a
system like openstack.</span> In fact, many people use
it for this purpose right now.</div>
<div><br>
</div>
<div>I discussed this with our team management and this is
something SaltStack wants to support.</div>
<div><br>
</div>
<div>Are there any specifics things that the salt minion
lacks right now to support this use case?</div>
</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<br></div></div>
David,<br>
<br>
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.<br></div></blockquote><div><br></div><div>That is the default setup. The salt-minion can also run in standalone mode without a master. </div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<br>
This is not desirable for a unified agent (atleast in the case of
Heat).<br>
<br>
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.<br>
<br>
A guest agent should have the following properties:<br>
* minimal library dependency chain<br></div></blockquote><div> </div><div>Salt only has a few dependencies <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
* no third-party server dependencies<br></div></blockquote><div><br></div><div>As mentioned above, the salt-minion can run without a salt master in standalone mode </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
* packaged in relevant cloudy distributions<br></div></blockquote><div> </div><div>The Salt Minion is packaged for all major (and many smaller) distributions. </div><div>RHEL/EPEL/Debian/Ubuntu/Gentoo/FreeBSD/Arch/MacOS</div>
<div>
There is also a Windows installer. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
In terms of features:<br>
* run shell commands<br>
* install files (with selinux properties as well)<br>
* create users and groups (with selinux properties as well)<br>
* install packages via yum, apt-get, rpm, pypi<br>
* start and enable system services for systemd or sysvinit<br>
* Install and unpack source tarballs<br>
* run scripts<br>
* Allow grouping, selection, and ordering of all of the above
operations<br></div></blockquote><div><br></div><div>Salt-Minion excels at all the above</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
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!<br></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Regards,<br>
-steve<br>
<br> </div></blockquote><div><br></div><div>Regards,</div><div><br></div><div>Dave </div></div>
</div></div>