<div dir="ltr">Let's not create architectural leaks here. Let there be only tasks, but let's create a really simple template for task that user will be able to easily fill only with the command itself.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 11, 2014 at 4:17 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>In most cases for plugin developers or fuel users it will be much</div><div>easier to just write command which he wants to run on nodes</div><div>instead of describing some abstract task which doesn't have</div><div>any additional information/logic and looks like unnecessary complexity.</div><div><br></div><div>But for complicated cases user will have to write some code for tasklib.</div><div><br></div><div>Thanks,</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 10, 2014 at 8:10 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">Hi,<div><br></div><div>you described transport mechanism for running commands based on facts, we have another one, which stores</div><div>all business logic in nailgun and only provides orchestrator with set of tasks to execute. This is not a problem.</div><div><br></div><div>I am talking about API for plugin writer/developer. And how implement it to be more "friendly"</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 10, 2014 at 6:46 PM, Aleksandr Didenko <span dir="ltr"><<a href="mailto:adidenko@mirantis.com" target="_blank">adidenko@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><div><div><div><div>Hi,<br><br></div>as for execution of arbitrary code across the OpenStack cluster - I was thinking of mcollective + fact filters:<br><br></div>1) we need to start using mcollective facts [0] [2] - we don't use/configure this currently<br></div>2) use mcollective execute_shell_command agent (or any other agent) with fact filter [1]<br><br>So, for example, if we have mcollective fact called "node_roles":<br></div></div>node_roles: "compute ceph-osd"<br></div><br><div><div><div>Then we can execute shell cmd on all compute nodes like this:<br><br>mco rpc execute_shell_command execute cmd="/some_script.sh" -F "node_role=/compute/"<br><code></code><code></code></div><div></div><div><br></div><div>Of course, we can use more complicated filters to run commands more precisely.<br></div><div><br>[0] <a href="https://projects.puppetlabs.com/projects/mcollective-plugins/wiki/FactsFacterYAML" target="_blank">https://projects.puppetlabs.com/projects/mcollective-plugins/wiki/FactsFacterYAML</a><br>[1] <a href="https://docs.puppetlabs.com/mcollective/reference/ui/filters.html#fact-filters" target="_blank">https://docs.puppetlabs.com/mcollective/reference/ui/filters.html#fact-filters</a><br>[2] <a href="https://docs.puppetlabs.com/mcollective/reference/plugins/facts.html" target="_blank">https://docs.puppetlabs.com/mcollective/reference/plugins/facts.html</a><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Wed, Sep 10, 2014 at 6:04 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi folks,<div><br></div><div>Some of you may know that there is ongoing work to achieve kindof data-driven orchestration </div><div>for Fuel. If this is new to you, please get familiar with spec:</div><div><br></div><div><a href="https://review.openstack.org/#/c/113491/" target="_blank">https://review.openstack.org/#/c/113491/</a><br></div><div><br></div><div>Knowing that running random command on nodes will be probably most usable type of</div><div>orchestration extension, i want to discuss our solution for this problem.</div><div><br></div><div>Plugin writer will need to do two things:</div><div><br></div><div>1. Provide custom task.yaml (i am using /etc/puppet/tasks, but this is completely configurable,</div><div> we just need to reach agreement) </div><div><br></div><div> /etc/puppet/tasks/echo/task.yaml</div><div> </div><div> with next content:</div><div> </div><div> type: exec</div><div> cmd: echo 1 </div><div><br></div><div>2. Provide control plane with orchestration metadata</div><div><br></div><div>/etc/fuel/tasks/echo_task.yaml</div><div><br></div><div>controller:</div><div> -</div><div> task: echo</div><div> description: Simple echo for you</div><div> priority: 1000</div><div>compute:</div><div><div>-</div><div> task: echo</div><div> description: Simple echo for you</div><div> priority: 1000</div></div><div><br></div><div>This is done in order to separate concerns of orchestration logic and tasks.</div><div><br></div><div>From plugin writer perspective it is far more usable to provide exact command in orchestration metadata itself, like:</div><div><br></div><div><div>/etc/fuel/tasks/echo_task.yaml</div><div><br></div><div>controller:</div><div> -</div><div> task: echo</div><div> description: Simple echo for you</div><div> priority: 1000</div></div><div> cmd: echo 1</div><div> type: exec</div><div><br></div><div>compute:</div><div>-</div><div><div><div> task: echo</div><div> description: Simple echo for you</div><div> priority: 1000</div></div><div> cmd: echo 1</div><div> type: exec</div></div><div><br></div><div>I would prefer to stick to the first, because there is benefits of using one interface between all tasks executors (puppet, exec, maybe chef), which will improve debuging and development process.</div><div><br></div><div>So my question is first - good enough? Or second is essential type of plugin to support?</div><div><br></div><div>If you want additional implementation details check:</div><div><a href="https://review.openstack.org/#/c/118311/" target="_blank">https://review.openstack.org/#/c/118311/</a><br></div><div><a href="https://review.openstack.org/#/c/113226/" target="_blank">https://review.openstack.org/#/c/113226/</a><br></div><div><br></div><div><br></div><div><br></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><br></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">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"><br>-- <br><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>