Open Stack

Hey folks,

Simon P. wrote:
> 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).

Simon, could you please explain do you need this at the first place? I
can imagine this case only if your two plugins are kinda dependent on
each other. In this case, it's better to do what was said by Andrew W.
- set 'Task Y' to require 'Task X' and that requirement will be
satisfied anyway (even if Task X doesn't exist in the graph).


Alex S. wrote:
> 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.

Yeah, I think that may be useful sometime. However, I'd prefer to
avoid anchor usage as much as possible. There's no guarantees that
other plugin didn't make any destructive actions early, that breaks
you later. Anchors is good way to resolve possible conflicts, but they
aren't bulletproof.

- igor

On Thu, Jan 28, 2016 at 1:31 PM, Bogdan Dobrelya <bdobrelia at mirantis.com> wrote:
> On 27.01.2016 14:44, Simon Pasquier 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?
>
> I created a kinda related bug [0] and submitted a patch [1] to MOS docs
> [2] to kill some entropy on the topic of tasks schema roles versus
> groups and using wildcards for basic and custom roles from plugins as
> well. There is also a fancy picture to clarify things a bit. Would be
> nice to put more details there about custom stages as well!
>
> If plugins are not aware of each other, they cannot be strictly ordered
> like "to be the very last in the deployment" as one and only shall be
> so. That is why "coordinating the execution of tasks
> between plugins without prior knowledge of which plugins were installed"
> looks very confusing for me. Though, maybe wildcards with the "skipped"
> task type may help to organize things better?
>
> Perhaps the Fuel plugins team could answer the question better.
>
> [0] https://bugs.launchpad.net/fuel/+bug/1538982
> [1] https://review.fuel-infra.org/16509
> [2]
> https://docs.mirantis.com/openstack/fuel/fuel-7.0/reference-architecture.html#task-based-deployment
>
>>
>> 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
>>
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __________________________________________________________________________
> 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