<p dir="ltr"><br>
On Jan 27, 2016 4:58 PM, "Andrew Woodward" <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>> wrote:<br>
><br>
> Simon, you should use the deployment_tasks.yaml interface (which will likely eventually move to '*/tasks.yaml' (to mimic library) This uses the same task system as granular deploy. you can set task ordering between known tasks and roles names, in the case that they are not registered they will simply be ignored.<br>
><br>
> The result will be that the engine will parse out the precise location for tasks to run in the graph (you can run outside of the post-deployment with them). In most cases, you will not need to specify precise ordering between the plugins. I know there is the odd case that two components need to modify the same parts, there are a couple of ways we can work this out, but it ultimately will come down to a case-by case until we solidify the config-db workflow </p>
<p dir="ltr">Kind of along this topic I've actually run into difficulties when trying to wedge a plugins tasks at the absolute end of a deployment using the deployment_tasks.yaml. I was only able to get it working reliably by using the tasks.yaml method. I feel that forcing plugin developers to know what possible tasks could be executed for all cases puts too much on them since we don't really supply good ways to get the task lists. It seems like you basically need to be a fuel dev to understand it. Before we get rid of tasks.yaml can we provide a mechanism for plugin devs could leverage to have tasks executes at specific points in the deploy process.  Basically provide the stage concept from tasks.yaml with documented task anchors? For my case it would have been nice to be able to pin to run after post deployment end.</p>
<p dir="ltr">-Alex</p>
<p dir="ltr">><br>
> On Wed, Jan 27, 2016 at 5:45 AM Simon Pasquier <<a href="mailto:spasquier@mirantis.com">spasquier@mirantis.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I see that tasks.yaml is going to be deprecated in the future MOS versions [1]. I've got one question regarding the ordering of tasks between different plugins.<br>
>> With tasks.yaml, it was possible to coordinate the execution of tasks between plugins without prior knowledge of which plugins were installed [2].<br>
>> For example, lets say we have 2 plugins: A and B. The plugins may or may not be installed in the same environment and the tasks execution should be:<br>
>> 1. Run task X for plugin A (if installed).<br>
>> 2. Run task Y for plugin B (if installed).<br>
>> 3. Run task Z for plugin A (if installed).<br>
>><br>
>> Right now, we can set task priorities like:<br>
>><br>
>> # tasks.yaml for plugin A<br>
>> - role: ['*']<br>
>>   stage: post_deployment/1000<br>
>>   type: puppet<br>
>>   parameters:<br>
>>     puppet_manifest: puppet/manifests/task_X.pp<br>
>>     puppet_modules: puppet/modules<br>
>><br>
>> - role: ['*']<br>
>>   stage: post_deployment/3000<br>
>>   type: puppet<br>
>>   parameters:<br>
>>     puppet_manifest: puppet/manifests/task_Z.pp<br>
>>     puppet_modules: puppet/modules<br>
>><br>
>> # tasks.yaml for plugin B<br>
>> - role: ['*']<br>
>>   stage: post_deployment/2000<br>
>>   type: puppet<br>
>>   parameters:<br>
>>     puppet_manifest: puppet/manifests/task_Y.pp<br>
>>     puppet_modules: puppet/modules<br>
>><br>
>> How would it be handled without tasks.yaml?<br>
>><br>
>> Regards,<br>
>> Simon<br>
>><br>
>> [1] <a href="https://review.openstack.org/#/c/271417/">https://review.openstack.org/#/c/271417/</a><br>
>> [2] <a href="https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order">https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order</a><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> -- <br>
><br>
> --<br>
><br>
> Andrew Woodward<br>
><br>
> Mirantis<br>
><br>
> Fuel Community Ambassador<br>
><br>
> Ceph Community<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
</p>