<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 6, 2015 at 11:16 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dmitry,<div>thanks for sharing CLI options. I'd like to clarify a few things.</div><span class=""><div><br></div><div>> <span style="font-size:12.8000001907349px">Also very important to understand that if task is mapped to role controller, </span><span style="font-size:12.8000001907349px">but node where you want to apply that task doesn't have this role - it wont be executed.</span></div></span><div><span style="font-size:12.8000001907349px">Is there a particular reason why we want to restrict a user to run an arbitrary task on a server, even if server doesn't have a role assigned? I think we should be flexible here - if I'm hacking something, I'd like to run arbitrary things.</span></div><span class=""><div><span style="font-size:12.8000001907349px"><br></span></div></span></div></blockquote><div>The way I've seen this work so far is the missing role in the graph simply wont be executed, not the requested role</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div><span style="font-size:12.8000001907349px"></span></div><div><span style="font-size:12.8000001907349px">>>> fuel node --node 1,2,3 --end netconfig</span><span style="font-size:12.8000001907349px"><br></span></div></span><div><span style="font-size:12.8000001907349px">I would replace --end -> --end-on, in order to show that task specified will run as well (to avoid </span>ambiguity<span style="font-size:12.8000001907349px">)</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div>This is separate question probably about CLI UX, but still - are we Ok with missing an action verb, like "deploy"? So it might be better to have, in my opinion:</div><div><span style="font-size:12.8000001907349px">fuel deploy --node 1,2,3 --end netconfig</span><br></div><span class=""><div><span style="font-size:12.8000001907349px"><br></span></div></span></div></blockquote><div>provision and deploy tasks are already under node so it makes some sense to keep them here unless everything moves</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div><span style="font-size:12.8000001907349px"></span></div><div>> <span style="font-size:12.8000001907349px">For example if one want to execute only netconfig successors:</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>>> fuel node --node 1,2,3 --start netconfig --skip netconfig</span><br></div></span><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">I would come up with shortcut for one task. To me, it would be way better to specify comma-separated tasks:</span><span style="font-size:small"> </span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>> fuel deploy --node 1,2,3 --task netconfig[,task2]</span></div></div></blockquote><div>this already appears to work as</div><div>fuel node --node 1,2,3 --task netconfig compute </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12.8000001907349px"><span style="font-size:small"> </span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px"></span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Question here: if netconfig depends on other tasks, will those be executed prior to netconfig? I want both options, execute with prior deps, and execute just one particular task.</span></div><span class=""><div style="font-size:12.8000001907349px"><br></div><div><span style="font-size:12.8000001907349px">> </span><span style="font-size:12.8000001907349px">Also we are working on deployment graph visualization</span></div></span><div><span style="font-size:12.8000001907349px">yes, this would be awesome to have. When I specify --start and --end, I'll want to know what is going to be executed in reality, before it gets executed. So something like dry-run which shows execution graph would be very helpful.</span></div></div></blockquote><div>We need to start with a better graph of everything that will run on each node and in which order, I've yet to see something that renders the whole graph including the requested deps on each node. It will be very useful for debugging.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>As a separate note here, a few question:</div><div><ol><li>If particular task fails to execute for some reason, what is the error handling? Will I be able to see puppet/deployment tool exception right in the same console, or should I check out some logs? We need to have perfect UX for errors. Those who will be using CLI to run particular tasks, will be dealing with errors for >95% of their time.</li></ol></div></div></blockquote><div>The puppet based tasks run and should show errors the same as legacy deployments or plugin tasks </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ol><li>I'd love to have some guidance on slave node as well. For instance, I want to run just netconfig on slave node. How can I do it?<br></li></ol></div></div></blockquote><div>fuel node --node 1 --tasks netconfig </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ol><li>If I stuck with error in task execution, which is in puppet. Can I modify puppet module on master node, and re-run the task? (assuming that updated module will be rsynced to slaves under deployment first) </li></ol></div></div></blockquote><div>that's exactly how it works </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Thanks Dmitry!</div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sat, Feb 7, 2015 at 12:16 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><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>Thank you for the excellent run-down of the CLI commands. I assume this will make its way into the developer documentation? I would like to know if you could point me to more information about the inner workings of granular deployment. Currently it's challenging to debug issues related to granular deployment. </div></blockquote><div><br></div></span><div>All tasks that are in scope of role are serialized right into deployment configuration that is consumed by astute. So it can be traced in the logs <br></div><div>(nailgun or astute) or in astute.yaml that is stored on node itself. Here is what it looks like [0].</div><div>Some other internals described in spec - <a href="https://review.openstack.org/#/c/113491/" target="_blank">https://review.openstack.org/#/c/113491/</a>.</div><div><br></div><div>For developer it makes sense to get familiar with networkx data structures [1], and then dive into debuging of [2].</div><div>But it is not an option for a day-to-day usage, and UX will be improved by graph visualizer [3].</div><div><br></div><div>One more option that can improve understanding is human-readable planner..</div><div>For example it can output smth like this:</div><div><br></div><div>>> fuel deployment plan --start hiera --end netconfig</div><div><br></div><div> Manifest hiera.pp will be executed on nodes [1,2,3]</div><div> Manifest netconfig will be executed on nodes [1,2]</div><div><br></div><div>But i am not sure is this thing really necessary, dependencies are trivial in comparison to puppet, and i hope it will take very little time to</div><div>understand how things are working :)</div><span><div><br></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>As an example there is a bug [0] where tasks appear to be run in the wrong order based on which combination of roles exist in the environment. However, it's not clear how to determine what decides which tasks to run and when (is it astute, fuel-library, etc.), where the data comes from. etc. </div></blockquote></span></div><div class="gmail_extra"><br></div><div class="gmail_extra">As for the bug - it may be a duplicate for <a href="https://launchpad.net/bugs/1417579" target="_blank">https://launchpad.net/bugs/1417579</a>, which was fixed by <a href="https://review.openstack.org/#/c/152511/" target="_blank">https://review.openstack.org/#/c/152511/</a></div><br>[0] <a href="http://paste.openstack.org/show/168298/" target="_blank">http://paste.openstack.org/show/168298/</a></div><div class="gmail_extra">[1] <a href="http://networkx.github.io/documentation/latest/tutorial/tutorial.html#directed-graphs" target="_blank">http://networkx.github.io/documentation/latest/tutorial/tutorial.html#directed-graphs</a></div><div class="gmail_extra">[2] <a href="https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_graph.py#L29" target="_blank">https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_graph.py#L29</a></div><div class="gmail_extra">[3] <a href="https://review.openstack.org/#/c/152434/" target="_blank">https://review.openstack.org/#/c/152434/</a></div></div>
<br></div></div><span class="">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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 class="gmail_signature">Andrew<br>Mirantis<br>Fuel community ambassador <br>Ceph community</div>
</div></div>