<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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"><span class=""><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></blockquote><div> </div><div>The reason it is not supported is that such behaviour will require two different endpoints, with quite similar functionality.</div><div>In most cases developer will benefit from relying on role mappings, for instance right now one will be able to test dependent tasks on</div><div>different nodes by next commands:</div><div>>> fuel node --node 1,2,3 --tasks corosync_primary corosync_slave</div><div>>> fuel node --node 1,2 --tasks controller_service compute_service</div><div>IMO it is reasonable requirement for developer to ensure that task is properly inserted into deployment configuration.</div><div><br></div><div>Also there was a discussion to implement an api that will bypass all nailgun logic and will allow to communicate directly with orchestrator hooks, like:</div><div><br></div><div>>> fuel exec < file_with_tasks.yaml</div><div><br></div><div>Where file_with_tasks filled with data consumable directly by orchestrator</div><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"><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></div></blockquote><div> </div><div>We may want to put everything that is related to deployment under one CLI namespace, but IMO we need to be consistent and regular deploy/provision should be migrated as well. '</div><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"><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></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>> fuel deploy --node 1,2,3 --task netconfig[,task2]</span></div></blockquote><div> </div><div>I dont like comma-separted notation at all, if majority will think that it is more readable than whitespace - lets do it.</div><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 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></blockquote><div> </div><div>When tasks provided with --tasks flag - no additional dependencies will be included. Traversal will be performed only with --end and --start flags. </div><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><span style="font-size:12.8000001907349px"></span></div><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></blockquote><div>There will be UI message that something with that id is failed. But developer will need to go for logs (astute preferably).</div><div>What you are suggesting is doable, but not that trivial.. We will check how much time this will take, and maybe there is other ways to improve deployment feedback.</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><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></blockquote><div>You mean completely bypassing fuel control plane? Developer will be able to use underlying tools directly, puppet apply, python, ruby, whatever </div><div>that task is using.</div><div>We may add a helper, to show all tasks endpoints in single place, but they can be found easily by usual grep..</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><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></blockquote></div>Rsync puppet is separate task, so one will need to execute:</div><div class="gmail_extra"><br></div><div class="gmail_extra">>> fuel node --node 1,2,3 --tasks rsync_core_puppet netconfig<br><br></div></div>