<div dir="ltr">Guys, <div><br></div><div>First of all we need to agree about what orchestration is. In terms of Fuel orchestration is task management (or scheduling) + task running. In other words an orchestrator needs to be able to get data (yaml, json, etc.) and to decide what to do, when and where and then do that. For task management we need to have a kind of logic like that is provided by Mistral. For launching it just needs to have a kind of transport like that is available when we use mcollective or saltstack or ssh. </div>
<div><br></div><div>As far as I know (I did research in Saltstack a year ago), Saltstack does not have mature management mechanism. What it has is so called "overstate" mechanism which allows one to write a script for managing tasks in multiple node environments like "launch task-1 on node-1, then launch task-2 on node-2 and then launch task-3 on node-1 again". It works, but it is semi-manual. I mean it is exactly what we already have and call it Astute. The only difference is that Astute is a wrapper around Mcollective.</div>
<div><br></div><div>The only advantages I see in using Saltstack instead of Mcollective is that it is written in Python (Mcollective still does not have python binding) and that it uses ZeroMQ. Maybe those advantages are not so subtle, but let's take a look carefully. </div>
<div><br></div><div>For example, the fact that Saltstack is written in Python allows us to use Saltstack directly from Nailgun. But I am absolutely sure that everyone will agree that would be a great architectural lack. If you ask me, Nailgun has to use an external task management service with highly outlined API such as Mistral. Mistral already has plenty of capabilities for that. Do we really need to implement all that stuff?</div>
<div><br></div><div>ZeroMQ is a great advantage if you have thousands of nodes. It is highly scalaeble. It is also allows one to avoid using one additional external service like Rabbit. Minus one point of failure, right? On the other hand, it brings us into the world of Saltstack with its own bugs despite its maturity. </div>
<div><br></div><div>Consequently, my personal preference is to concentrate on splitting puppet code into independent tasks and using Mistral for resolving task dependencies. As our transport layer we'll then be able to use whatever we want (Saltstack, Mcollective, bare ssh, any kind of custom implementation, etc.)</div>
<div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div>Vladimir Kozhukalov</div></div>
<br><br><div class="gmail_quote">On Fri, Jun 13, 2014 at 8:45 AM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Dmitry,<div>please read design doc attached to <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization</a>.</div>
<div>I think it can serve as a good source of requirements which we have, and then we can see what tool is the best.</div><div><br></div><div>Regards,</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br>
<br><div class="gmail_quote">On Thu, Jun 12, 2014 at 12:28 PM, Vladimir Kuklin <span dir="ltr"><<a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Guys, what we really need from orchestration tool is an ability orchestrate a big amount of task accross the nodes with all the complicated dependencies, dynamic actions (e.g. what to do on failure and on success) and parallel execution including those, that can have no additional software installed somewhere deep in the user's infrastructure (e.g. we need to send a RESTful request to vCenter). And this is the usecase of our pluggable architecture. I am wondering if saltstack can do this.</div>
<div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Wed, Jun 11, 2014 at 9:08 PM, Sergii Golovatiuk <span dir="ltr"><<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi,<br><br></div>That would be nice to compare Ansible and Salt. They are both Python based. Also, Ansible has pull model also. Personally, I am big fan of Ansible because of its simplicity and speed of playbook development.<span><font color="#888888"><br>
<br></font></span></div><span><font color="#888888">~Sergii <br></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 11, 2014 at 1:21 PM, Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">well, i dont have any comparison chart, i can work on one based on requirements i've provided in initial letter, but:<div>
i like ansible, but it is agentless, and it wont fit well in our current model of communication between nailgun and orchestrator<div>
cloudify - java based application, even if it is pluggable with other language bindings - we will benefit from application in python</div></div><div>salt is been around for 3-4 years, and simply compare github graphs, it one of the most used and active projects in python community</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://github.com/stackforge/mistral/graphs/contributors" target="_blank">https://github.com/stackforge/mistral/graphs/contributors</a><br></div><div class="gmail_extra">
<a href="https://github.com/saltstack/salt/graphs/contributors" target="_blank">https://github.com/saltstack/salt/graphs/contributors</a><br></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Jun 11, 2014 at 1:04 PM, Sergii Golovatiuk <span dir="ltr"><<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.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 dir="ltr"><div><div>Hi,<br><br></div>There are many mature orchestration applications (Salt, Ansible, Cloudify, Mistral). Is there any comparison chart? That would be nice to compare them to understand the maturity level. Thanks<span><font color="#888888"><br>
<br></font></span></div><span><font color="#888888">~Sergii<br></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 11, 2014 at 12:48 PM, Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@mirantis.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 dir="ltr">Actually i am proposing salt as alternative, the main reason - salt is mature, feature full orchestration solution, that is well adopted even by our internal teams</div>
<div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Jun 11, 2014 at 12:37 PM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.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 dir="ltr"><div>Hi,</div><div><br></div><div>As far as I remember we wanted to replace Astute with Mistral [1], do we really want to have some intermediate steps (I mean salt) to do it?</div><div><br></div><div>[1] <a href="https://wiki.openstack.org/wiki/Mistral" target="_blank">https://wiki.openstack.org/wiki/Mistral</a></div>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 11, 2014 at 10:38 AM, Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@mirantis.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 dir="ltr">Yes, in my opinion salt can completely replace astute/mcollective/rabbitmq.<div>
Listen and respond to the events generated by nailgun, or any other plugin - not a problem.</div>
<div>There is already some kind of plugin for salt that adds ability to execute puppet on minions (agents) [1]</div>
<div><br></div><div>[1] <a href="http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.puppet.html" target="_blank">http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.puppet.html</a></div></div><div>
<div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Jun 10, 2014 at 4:06 PM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.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 dir="ltr">Interesting stuff.<div>Do you think that we can get rid of Astute at some point being purely replaced by Salt?</div><div>And listening for the commands from Fuel?</div><div><br></div><div>Can you please clarify, does the suggested approach implies that we can have both puppet & SaltStack? Even if you ever switch to anything different, it is important to provide a smooth and step-by-step way for it.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Mon, Jun 9, 2014 at 6:05 AM, Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@mirantis.com</a>></span> wrote:<br>
</div></div><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><div><div dir="ltr"><div>Hi folks,</div>
<div><br></div><div>I know that sometime ago saltstack was evaluated to be used as orchestrator in fuel, so I've prepared some initial specification, that addresses basic points of integration, and general requirements for orchestrator.</div>
<div><br></div><div>In my opinion saltstack perfectly fits our needs, and we can benefit from using mature orchestrator, that has its own community. I still dont have all the answers, but , anyway, i would like to ask all of you to start a review for specification</div>
<div><br></div><div><a href="https://docs.google.com/document/d/1uOHgxM9ZT_2IdcmWvgpEfCMoV8o0Fk7BoAlsGHEoIfs/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1uOHgxM9ZT_2IdcmWvgpEfCMoV8o0Fk7BoAlsGHEoIfs/edit?usp=sharing</a></div>
<div><br></div><div>I will place it in fuel-docs repo as soon as specification will be full enough to start POC, or if you think that spec should placed there as is, i can do it now</div><div><br></div><div>Thank you</div>
</div>
<br></div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Mike Scherbakov<br>#mihgen<br><br>
</font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br></blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>
Skype kuklinvv<br>
45bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Mike Scherbakov<br>#mihgen<br><br>
</div>
</div></div><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>
<br></blockquote></div><br></div>