[openstack-dev] [Fuel][Plugins] Tasks ordering between plugins
Alex Schultz
aschultz at mirantis.com
Thu Jan 28 01:14:56 UTC 2016
On Jan 27, 2016 4:58 PM, "Andrew Woodward" <xarses at gmail.com> wrote:
>
> 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.
>
> 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
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.
-Alex
>
> On Wed, Jan 27, 2016 at 5:45 AM Simon Pasquier <spasquier at mirantis.com>
wrote:
>>
>> Hi,
>>
>> 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.
>> With tasks.yaml, it was possible to coordinate the execution of tasks
between plugins without prior knowledge of which plugins were installed [2].
>> 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:
>> 1. Run task X for plugin A (if installed).
>> 2. Run task Y for plugin B (if installed).
>> 3. Run task Z for plugin A (if installed).
>>
>> Right now, we can set task priorities like:
>>
>> # tasks.yaml for plugin A
>> - role: ['*']
>> stage: post_deployment/1000
>> type: puppet
>> parameters:
>> puppet_manifest: puppet/manifests/task_X.pp
>> puppet_modules: puppet/modules
>>
>> - role: ['*']
>> stage: post_deployment/3000
>> type: puppet
>> parameters:
>> puppet_manifest: puppet/manifests/task_Z.pp
>> puppet_modules: puppet/modules
>>
>> # tasks.yaml for plugin B
>> - role: ['*']
>> stage: post_deployment/2000
>> type: puppet
>> parameters:
>> puppet_manifest: puppet/manifests/task_Y.pp
>> puppet_modules: puppet/modules
>>
>> How would it be handled without tasks.yaml?
>>
>> Regards,
>> Simon
>>
>> [1] https://review.openstack.org/#/c/271417/
>> [2] https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order
>>
__________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160127/320d309e/attachment.html>
More information about the OpenStack-dev
mailing list