<div dir="ltr"><div><div><div>Hi, Dmitry<br><br></div>1) In my opinion, we should not have any hardcoded stages in task list. These should be virtual roles, that you can use as a vertex in dependency graph to aggregate and group tasks. Just like it is done in puppet with anchors. <br></div><div><br>Also, we may need to look into some meta-data related approach, e.g. using tagging of tasks, nodes and roles. For example, we could mark rabbitmq, pacemaker and galera installation with "ha" tags and then use this tag when specifying dependency for other tasks.<br></div><div><br>2) Also, we need to use generic approach for dependencies specification: "before" and "after" for tasks. There is no need to use integer values for priorities, as all we need to do is just provide an ordered set of tasks - there is no need for particular numeric values.<br><br></div>3) Regarding roles - role is just an aggregational entity that combines several tasks<br><br></div>4) Regarding dependency and role keywords: I think, we need to look into some kind of query language that can satisfy our requirements. E.g., I can easily imagine a usecase when we need to do some dynamical calculation of nodes on which to execute the particular task. I think, we could look into Mistral and Murano projects doing some of the similar stuff and decide whether their approach fits our needs. As an example, we may need to exclude the node being added from a particular set of tasks. Imagine, we just added a controller. After we deployed it, all we need is to just update several configs on the nodes and restart/reload particular services, e.g. haproxy on controllers and nova-compute services on the computes. In this case, you will need to tag a node with, let's say "new-node" tag and then exclude it from execution list by using something like "!tags.include("new-node")"<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 10, 2014 at 10:21 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Hi team,</div><div>After several discussions i want to propose generic format</div><div>for describing deployment tasks, this format is expected to cover</div><div>all tasks (e.g pre-deployment and post-deployment), also it should cover</div><div>different actions like upgrade/patching</div><div><br></div><div>action: upload_file</div><div>id: upload_astute</div><div>roles: *</div><div>parameters:</div><div> input: $.data - this is internal mistral thing</div><div> timeout: 50</div><div><br></div><div>action: tasklib</div><div>id: generate_keys</div><div>stages: [pre-deployment]</div><div>roles: master</div><div>parameters:</div><div> timeout: 60</div><div> command: generate/keys</div><div> type: puppet</div><div> manifest: /etc/puppet/manifests/key_generator.pp</div><div><br></div><div>action: tasklib</div><div>id: rsync_puppet</div><div>stages: [pre-node]</div><div>requires: [upload_astute]</div><div>parameters:</div><div> timeout: 100</div><div> command: rsync/stuff</div><div> type: shell</div><div> cmd: python rsync.py</div><div><br></div><div>action: tasklib</div><div>id: ceph</div><div>roles: [ceph-osd, ceph-mon]</div><div>requires: [rsync_puppet]</div><div>parameters:</div><div> timeout: 100</div><div> command: deployment/ceph</div><div> type: puppet</div><div> manifest: /etc/puppet/manifests/ceph.pp</div><div><br></div><div>action: tasklib</div><div>id: glance/image</div><div>roles: [controller, primary-controller]</div><div>stages: [post-deployment]</div><div>parameters:</div><div> timeout: 100</div><div> command: deployment/glance/image</div><div> type: shell</div><div> cmd: python upload_image.py</div><div><br></div><div>Let me provide some clarifications:</div><div>1. As example, we want to generate keys strictly before deployment, and the 1st way to solve </div><div>it is to introduce concept of stages, e.g pre-deployment, main, upgrade, post-deployment. </div><div>Another one would be to use virtual roles and/or virtual tasks like deployment_started, deployment_ended. </div><div>We need to consider both, but stages it is what we are using now, and i am just trying to generalize and make it data-driven.</div><div>2. Another internal thing is roles. As you can see in this configs there is 2</div><div>specific keywords for roles:</div><div> * - means task should be executed on all roles</div><div> master - task should be only executed on fuel master node</div><div>All other roles should be entities from fuel. If you know other exceptions - lets discuss them.</div><div><br></div><div>I would like to ask team for 2 things:</div><div>1. Examine approach and ask questions about any specific tasks, in order to test</div><div>this approach for sanity.</div><div>2. If you think that some of the keywords in configuration is not</div><div>appropriate, lets discuss it. For example we can not agree on term "stage",</div><div>because it is too widely used and basically we need another one.</div><div><br></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>