<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 29, 2016 at 4:27 PM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey folks,<br>
<span class=""><br>
Simon P. wrote:<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>
</span>Simon, could you please explain do you need this at the first place? I<br>
can imagine this case only if your two plugins are kinda dependent on<br>
each other. In this case, it's better to do what was said by Andrew W.<br>
- set 'Task Y' to require 'Task X' and that requirement will be<br>
satisfied anyway (even if Task X doesn't exist in the graph).<br></blockquote><div><br></div><div>Indeed, I didn't know that it was supported. I had the (false) impression that required tasks had to exist in the first place.<br></div><div>If this works then it should be ok for me.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
Alex S. wrote:<br>
> Before we get rid of tasks.yaml can we provide a mechanism for plugin<br>
> devs could leverage to have tasks executes at specific points in the<br>
> deploy process.<br>
<br>
</span>Yeah, I think that may be useful sometime. However, I'd prefer to<br>
avoid anchor usage as much as possible. There's no guarantees that<br>
other plugin didn't make any destructive actions early, that breaks<br>
you later. Anchors is good way to resolve possible conflicts, but they<br>
aren't bulletproof.<br>
<span class="HOEnZb"><font color="#888888"><br>
- igor<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Thu, Jan 28, 2016 at 1:31 PM, Bogdan Dobrelya <<a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a>> wrote:<br>
> On 27.01.2016 14:44, Simon Pasquier wrote:<br>
>> Hi,<br>
>><br>
>> I see that tasks.yaml is going to be deprecated in the future MOS<br>
>> versions [1]. I've got one question regarding the ordering of tasks<br>
>> between different plugins.<br>
>> With tasks.yaml, it was possible to coordinate the execution of tasks<br>
>> 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<br>
>> 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>
> I created a kinda related bug [0] and submitted a patch [1] to MOS docs<br>
> [2] to kill some entropy on the topic of tasks schema roles versus<br>
> groups and using wildcards for basic and custom roles from plugins as<br>
> well. There is also a fancy picture to clarify things a bit. Would be<br>
> nice to put more details there about custom stages as well!<br>
><br>
> If plugins are not aware of each other, they cannot be strictly ordered<br>
> like "to be the very last in the deployment" as one and only shall be<br>
> so. That is why "coordinating the execution of tasks<br>
> between plugins without prior knowledge of which plugins were installed"<br>
> looks very confusing for me. Though, maybe wildcards with the "skipped"<br>
> task type may help to organize things better?<br>
><br>
> Perhaps the Fuel plugins team could answer the question better.<br>
><br>
> [0] <a href="https://bugs.launchpad.net/fuel/+bug/1538982" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1538982</a><br>
> [1] <a href="https://review.fuel-infra.org/16509" rel="noreferrer" target="_blank">https://review.fuel-infra.org/16509</a><br>
> [2]<br>
> <a href="https://docs.mirantis.com/openstack/fuel/fuel-7.0/reference-architecture.html#task-based-deployment" rel="noreferrer" target="_blank">https://docs.mirantis.com/openstack/fuel/fuel-7.0/reference-architecture.html#task-based-deployment</a><br>
><br>
>><br>
>> Regards,<br>
>> Simon<br>
>><br>
>> [1] <a href="https://review.openstack.org/#/c/271417/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/271417/</a><br>
>> [2] <a href="https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order</a><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" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> --<br>
> Best regards,<br>
> Bogdan Dobrelya,<br>
> Irc #bogdando<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>