<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/09/2013 09:41 AM, David Boucha
wrote:<br>
</div>
<blockquote
cite="mid:CAJJqF90Gm2KVMAmL3OO0x4QvyEg+a4rMZ1YFjbreZBqampGnCw@mail.gmail.com"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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>
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>
<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>
* no third-party server dependencies<br>
* packaged in relevant cloudy distributions<br>
<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>
<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>
<br>
Regards,<br>
-steve<br>
<br>
<br>
<blockquote
cite="mid:CAJJqF90Gm2KVMAmL3OO0x4QvyEg+a4rMZ1YFjbreZBqampGnCw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">-- <br>
<div dir="ltr">
<div
style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif"><font
color="#666666" face="verdana, sans-serif">Dave
Boucha | Sr. Engineer</font></div>
<div
style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif"><font
color="#666666" face="verdana, sans-serif"><br>
</font></div>
<div
style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif"><span
style="color:rgb(34,34,34);font-family:arial;font-size:small">Join us at
SaltConf, </span><span
style="color:rgb(34,34,34);font-family:arial;font-size:small"><span>Jan.
28-30, 2014</span></span><span
style="color:rgb(34,34,34);font-family:arial;font-size:small"> in
Salt Lake City. </span><a moz-do-not-send="true"
href="http://www.saltconf.com/"
style="color:rgb(17,85,204);font-family:arial;font-size:small"
target="_blank">www.saltconf.com</a><font
color="#666666" face="verdana, sans-serif"><br>
</font></div>
<span
style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
<div><br>
</div>
<div><img moz-do-not-send="true"
src="http://1.bp.blogspot.com/-xMUn4pgJgvw/UKWeJOl4UXI/AAAAAAAAAVQ/3mEvwY-Zsmk/s320/Saltstack-logo-white.jpg"
height="39" width="200"><br>
</div>
5272 South College Drive, Suite 301 | Murray, UT 84123</span><br
style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
<b
style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">office</b><span
style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"> </span><a
moz-do-not-send="true" value="+12126266618"
style="color:rgb(17,85,204);font-size:13px;font-family:arial,sans-serif">801-305-3563</a><br
style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
<a moz-do-not-send="true" href="mailto:dave@saltstack.com"
style="color:rgb(17,85,204);font-size:13px;font-family:arial,sans-serif"
target="_blank" class="ci-email ci-contact"><span
style="color:blue">dave@saltstack.com</span></a><span
style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"> | </span><span
style="color:blue;font-size:13px;font-family:arial,sans-serif"><a
moz-do-not-send="true" href="http://saltstack.com/"
style="color:rgb(17,85,204)" target="_blank">www.saltstack.com</a></span></div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>