<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1yp" class="a3s" style="overflow:hidden">not to prolong single mode, I'd like to see it die. However we will<br>
need to be able to add, change, remove, or noop portions of the tasks<br>
graph in the future. Many of the plugins that cant currently be built<br>
would rely on being able to sub out parts of the graph. How is that<br>
going to factor into granular deployments?</div></blockquote></div><div class="gmail_extra"><br></div>There is several ways to achieve "noop" task:</div><div class="gmail_extra"><br>1. By condition on task itself (same expression parser that is used for UI validation).</div><div class="gmail_extra">Right now we are able to add condtion like, cluster:mode != multinode, </div><div class="gmail_extra">but the problem is additional complexity to support different chains of tasks, and additional refactoring in library.</div><div class="gmail_extra">2. Skip particular task in deployment API call</div><div class="gmail_extra"><br></div><div class="gmail_extra">As for plugins and add/stubout/change - all of this is possible, there is no plugins API for that stuff,</div><div class="gmail_extra">and we will need to think what exactly we want to expose, but from granular deployment perspective </div><div class="gmail_extra">it is just a matter of changing data for particular task in graph </div></div>