<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 7, 2015 at 11:12 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Swann,<br>
<span><br>
> However, we still need deployment order between independent<br>
> plugins and it seems impossible to define the priorities<br>
<br>
</span>There's no such things like priorities for now.. perhaps we can<br>
introduce some kind of anchors instead of priorities, but that's<br>
another story.<br></blockquote><div>yes its another story for next release(s), anchors could reuse the actual convention of ranges used (disk, network, software, monitoring)</div><div>that said I no sure anchors are sufficient, we still need priorities to specify orders for independant and/or optional plugins (they don't know each other)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Currently the only way to synchronize two plugins is to make one to<br>
know about other one. That means you need to properly setup "requires"<br>
field:<br>
<br>
    - id: my-plugin-b-task<br>
      type: puppet<br>
      role: [my-plugin-b-role]<br>
      required_for: [post_deployment_end]<br>
      requires: [post_deployment_start, PLUGIN-A-TASK]<br>
      parameters:<br>
        puppet_manifest: some-puppet.pp<br>
        puppet_modules: /etc/puppet/modules<br>
        timeout: 3600<br>
        cwd: /<br>
<br></blockquote><div>We thought about this solution _but_ in our case we cannot because the plugin is optional and may not be installed/enabled. So I guess this will break things if we reference in 'require' a nonexistent plugin-a-task.</div><div>For example with LMA plugins, the LMA-Collector plugin must be deployed/installed before LMA-Infrastructure-Alerting plugin (to avoid false alerts UNKNOWN state) but the last may not be enabled for the deployment.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Thanks,<br>
Igor<br>
<div><div><br></div></div></blockquote><div><br></div><div>About tasks.yaml, we must support it until an equivalent 'deployment order' is implemented with plugin-custom-role feature.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>
On Mon, Sep 7, 2015 at 11:31 AM, Swann Croiset <<a href="mailto:scroiset@mirantis.com" target="_blank">scroiset@mirantis.com</a>> wrote:<br>
> Hi fuelers,<br>
><br>
> We're currently porting nearly all LMA plugins to the new plugin fwk 3.0.0<br>
> to leverage custom role capabilities.<br>
> That brings up a lot of simplifications for node assignment, disk<br>
> management, network config, reuse core tasks and so on .. thanks to the fwk.<br>
><br>
> However, we still need deployment order between independent plugins and it<br>
> seems impossible to define the priorities [0] in deployment_tasks.yaml,<br>
> The only way to preserve deployment order would be to keep tasks.yaml too.<br>
><br>
> So, I'm wondering if this is the recommended solution to address plugins<br>
> order deployment with plugin fwk 3.0.0?<br>
> And furthermore if tasks.yaml will still be supported in future by the<br>
> plugin fwk or if the fwk shouldn't evolve  by adding priorities definitions<br>
> in deployment_tasks.yaml ?<br>
><br>
> Thanks<br>
><br>
> [0] <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>
</div></div>> __________________________________________________________________________<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>
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>
</blockquote></div><br></div></div>