<div dir="ltr">Hello Thomas,<div><br></div><div>I do understand your feelings. The problem is there were already many points raised both pro and contra adopting Salt as an agent. And so far no consensus was reached on that matter. Maybe someone else is willing to step out and write a PoC for Salt-based agent? Then we can agree on a functionality PoC should implement and compare the implementations. The PoCs also can reveal limitations we currently don't see.</div>
<div><br></div><div>Thanks,</div><div><br></div><div>Dmitry</div><div><br></div><div> </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/17 Thomas Herve <span dir="ltr"><<a href="mailto:thomas.herve@enovance.com" target="_blank">thomas.herve@enovance.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> The discussion didn't result in a consensus, but it did revealed a great<br>
> number of things to be accounted. I've tried to summarize top-level points<br>
> in the etherpad [1]. It lists only items everyone (as it seems to me) agrees<br>
> on, or suggested options where there was no consensus. Let me know if i<br>
> misunderstood or missed something. The etherpad does not list<br>
> advantages/disadvantages of options, otherwise it just would be too long.<br>
> Interested people might search the thread for the arguments :-) .<br>
><br>
> I've thought it over and I agree with people saying we need to move further.<br>
> Savanna needs the agent and I am going to write a PoC for it. Sure the PoC<br>
> will be implemented in project-independent way. I still think that Salt<br>
> limitations overweight its advantages, so the PoC will be done on top of<br>
> oslo.messaging without Salt. At least we'll have an example on how it might<br>
> look.<br>
><br>
> Most probably I will have more questions in the process, for instance we<br>
> didn't finish discussion on enabling networking for the agent yet. In that<br>
> case I will start a new, more specific thread in the list.<br>
<br>
</div></div>Hi Dimitri,<br>
<br>
While I agree that using Salt's transport may be wrong for us, the module system they have is really interesting, and a pretty big ecosystem already. It solved things like system-specific information, and it has a simple internal API to create modules. Redoing something from scratch Openstack-specific sounds like a mistake to me. As Salt seems to be able to work in a standalone mode, I think it'd be interesting to investigate that.<br>

<br>
Maybe it's worth separating the discussion between how to deliver messages to the servers (oslo.messaging, Marconi, etc), and what to do on the servers (where I think Salt is a great contender).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Thomas<br>
</font></span><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></div>