<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 9, 2013 at 11:19 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Steven Dake's message of 2013-12-09 09:41:06 -0800:<br>
<div class="im">> On 12/09/2013 09:41 AM, David Boucha wrote:<br>
> > On Sat, Dec 7, 2013 at 11:09 PM, Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a><br>
</div><div class="im">> > <mailto:<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>>> wrote:<br>
> ><br>
> ><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">mordred@inaugust.com</a><br>
</div><div><div class="h5">> > <mailto:<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>>> wrote:<br>
> > >><br>
> > ><br>
> > >> I suggested salt because we could very easily make trove and<br>
> > savana into<br>
> > >> salt masters (if we wanted to) just by having them import salt<br>
> > library<br>
> > >> and run an api call. When they spin up nodes using heat, we<br>
> > could easily<br>
> > >> have that to the cert exchange - and the admins of the site<br>
> > need not<br>
> > >> know _anything_ about salt, puppet or chef - only about trove<br>
> > 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>
> > Yes. You can have multiple salt masters.<br>
> ><br>
> > > Can salt minions affect each other? Could one pretend to be a<br>
> > master,<br>
> > > or snoop requests/responses to another minion?<br>
> ><br>
> > Yes and no. By default no - and this is protected by key<br>
> > 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<br>
> > allow it<br>
> > inject specific command requests back up into the master. We use<br>
> > 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,<br>
> > so I<br>
> > think they answer you're looking for is no.<br>
> ><br>
> > > Is salt limited: is it possible to assert that we *cannot* run<br>
> > > arbitrary code over salt?<br>
> ><br>
> > In as much as it is possible to assert that about any piece of<br>
> > 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"<br>
> > rather<br>
> > than "here, have some python and run it"<br>
> ><br>
> > Monty<br>
> ><br>
> ><br>
> ><br>
> > Salt was originally designed to be a unified agent for a system like<br>
> > openstack. In fact, many people use it for this purpose right now.<br>
> ><br>
> > I discussed this with our team management and this is something<br>
> > SaltStack wants to support.<br>
> ><br>
> > Are there any specifics things that the salt minion lacks right now to<br>
> > support this use case?<br>
> ><br>
><br>
> David,<br>
><br>
> If I am correct of my parsing of the salt nomenclature, Salt provides a<br>
> Master (eg a server) and minions (eg agents that connect to the salt<br>
> 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*<br>
> dependencies into OpenStack. Requiring a salt master (or a puppet<br>
> master, etc) in my view is a non-starter for a unified guest agent<br>
> proposal. Now if a heat user wants to use puppet, and can provide a<br>
> puppet master in their cloud environment, that is fine, as long as it is<br>
> optional.<br>
><br>
<br>
</div></div>What if we taught Heat to speak salt-master-ese? AFAIK it is basically<br>
an RPC system. I think right now it is 0mq, so it would be relatively<br>
straight forward to just have Heat start talking to the agents in 0mq.<br>
<div class="im"><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>
<br>
</div>That last one only matters if the distributions won't add things like<br>
agents to their images post-release. I am pretty sure "work well in<br>
OpenStack" is important for server distributions and thus this is at<br>
least something we don't have to freak out about too much.<br>
<div class="im"><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>
<br>
</div>All of those things are general purpose low level system configuration<br>
features. None of them will be needed for Trove or Savanna. They need<br>
to do higher level things like run a Hadoop job or create a MySQL user.<br>
<div class="im"><br>
> Agents are a huge pain to maintain and package. It took a huge amount<br>
> of willpower to get cloud-init standardized across the various<br>
> distributions. We have managed to get heat-cfntools (the heat agent)<br>
> into every distribution at this point and this was a significant amount<br>
> of work. We don't want to keep repeating this process for each<br>
> OpenStack project!<br>
><br>
<br>
</div>cloud-init is special because it _must_ be in the image to be relevant.<br>
It is the early-boot enabler of all other agents. The effort that happened<br>
there shouldn't ever have to happen again as long as we are good about<br>
always noting when something is an early-boot feature versus an ongoing<br>
management feature.<br>
<br>
Even with it packaged, we still can only use the lowest common denominator<br>
among popular distributions until the new feature arrives there, so it is<br>
really not a great idea to base anything forward-thinking on cloud-init<br>
features. What I expect to generally happen is when cloud-init grows<br>
a feature, whole swathes of specialized code will be deprecated and<br>
replaced with small snippets of declarations for cloud-init. But the<br>
old code will have to keep working until the old cloud-init dies.<br>
<br>
What we're talking about is an agent that enables other workloads. Heat's<br>
general case is different from Savanna and Trove's. Both Savanna and<br>
Trove build custom images and just spin those up precisely because it<br>
is not efficient to use a general purpose distribution to do something<br>
narrowly focused like host a database or map/reduce software.<br>
<br>
However, there is enough overlap in what Heat wants to do that it makes<br>
sense that we should try to use the same agent for Heat users if<br>
possible.<br>
<br>
The complication in this discussion I think comes from the fact that we<br>
really have three distinct goals:<br>
<br>
a. Enable communication in and out of private networks.<br>
b. Enable high level control of in-instance software.<br>
c. Light-weight general purpose post-boot customization.<br>
<br>
I think for (a) we have neutron-metadata-agent which could be enhanced<br>
to be more general instead of just forwarding EC2 metadata.<br>
<br>
For (b) salt-minion with Trove/Savanna specific plugins would fit the<br>
bill as long as we can teach Heat to speak salt-master. This does not<br>
change the dependency graph since Trove and Savanna will already be<br>
deferring infrastructure management to Heat.<br></blockquote><div><br></div><div>Salt has a powerful python api</div><div><br></div><div>import salt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For (c) I have always liked cfn-init for light-weight post-boot<br>
customization and I think it should just be kept around and taught<br>
to speak the protocol we validate in (b). However, if (b) is in fact<br>
salt's protocol, it would make sense to just make it easy to manage<br>
salt and let salt's default rules take over. Since we've also decided<br>
to make it easy to make puppet and chef rules easy to specify in HOT,<br>
this fits nicely with current plans.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><font face="verdana, sans-serif" color="#666666">Dave Boucha | Sr. Engineer</font></div>
<div style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><font face="verdana, sans-serif" color="#666666"><br></font></div><div style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<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 href="http://www.saltconf.com/" style="color:rgb(17,85,204);font-family:arial;font-size:small" target="_blank">www.saltconf.com</a><font face="verdana, sans-serif" color="#666666"><br>
</font></div><span style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255);color:rgb(34,34,34)"><div><br></div><div><img src="http://1.bp.blogspot.com/-xMUn4pgJgvw/UKWeJOl4UXI/AAAAAAAAAVQ/3mEvwY-Zsmk/s320/Saltstack-logo-white.jpg" width="200" height="39"><br>
</div>5272 South College Drive, Suite 301 | Murray, UT 84123</span><br style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255);color:rgb(34,34,34)"><b style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255);color:rgb(34,34,34)">office</b><span style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255);color:rgb(34,34,34)"> </span><a value="+12126266618" style="color:rgb(17,85,204);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">801-305-3563</a><br style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255);color:rgb(34,34,34)">
<a href="mailto:dave@saltstack.com" style="color:rgb(17,85,204);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)" target="_blank"><span style="color:blue">dave@saltstack.com</span></a><span style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255);color:rgb(34,34,34)"> | </span><span style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255);color:blue"><a href="http://saltstack.com/" style="color:rgb(17,85,204)" target="_blank">www.saltstack.com</a></span></div>
</div></div>