Open Stack

> 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)

If you need this, you're probably doing something wrong. Priorities
won't solve your problem here, because plugins will need to know about
priorities in other plugins and that's weird. The only working
solution here is to make plugin to know about other plugin if it's
important to make deployment precisely after other plugin.

> So I guess this will break things if we reference in 'require' a
> nonexistent plugin-a-task.

That's true. I think the right case here is to implement some sort of
conditional tasks, so different tasks will be executed in different
cases.

> About tasks.yaml, we must support it until an equivalent 'deployment order'
> is implemented with plugin-custom-role feature.

This is not about plugin-custom-role, this is about our task
deployment framework. I heard there were some plans on its
improvements.

Regards,
Igor

On Mon, Sep 7, 2015 at 3:27 PM, Swann Croiset <scroiset at mirantis.com> wrote:
>
>
> On Mon, Sep 7, 2015 at 11:12 AM, Igor Kalnitsky <ikalnitsky at mirantis.com>
> wrote:
>>
>> Hi Swann,
>>
>> > However, we still need deployment order between independent
>> > plugins and it seems impossible to define the priorities
>>
>> There's no such things like priorities for now.. perhaps we can
>> introduce some kind of anchors instead of priorities, but that's
>> another story.
>
> yes its another story for next release(s), anchors could reuse the actual
> convention of ranges used (disk, network, software, monitoring)
> 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)
>
>
>>
>> Currently the only way to synchronize two plugins is to make one to
>> know about other one. That means you need to properly setup "requires"
>> field:
>>
>>     - id: my-plugin-b-task
>>       type: puppet
>>       role: [my-plugin-b-role]
>>       required_for: [post_deployment_end]
>>       requires: [post_deployment_start, PLUGIN-A-TASK]
>>       parameters:
>>         puppet_manifest: some-puppet.pp
>>         puppet_modules: /etc/puppet/modules
>>         timeout: 3600
>>         cwd: /
>>
> 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.
> 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.
>
>> Thanks,
>> Igor
>>
>
> About tasks.yaml, we must support it until an equivalent 'deployment order'
> is implemented with plugin-custom-role feature.
>
>>
>> On Mon, Sep 7, 2015 at 11:31 AM, Swann Croiset <scroiset at mirantis.com>
>> wrote:
>> > Hi fuelers,
>> >
>> > We're currently porting nearly all LMA plugins to the new plugin fwk
>> > 3.0.0
>> > to leverage custom role capabilities.
>> > That brings up a lot of simplifications for node assignment, disk
>> > management, network config, reuse core tasks and so on .. thanks to the
>> > fwk.
>> >
>> > However, we still need deployment order between independent plugins and
>> > it
>> > seems impossible to define the priorities [0] in deployment_tasks.yaml,
>> > The only way to preserve deployment order would be to keep tasks.yaml
>> > too.
>> >
>> > So, I'm wondering if this is the recommended solution to address plugins
>> > order deployment with plugin fwk 3.0.0?
>> > And furthermore if tasks.yaml will still be supported in future by the
>> > plugin fwk or if the fwk shouldn't evolve  by adding priorities
>> > definitions
>> > in deployment_tasks.yaml ?
>> >
>> > Thanks
>> >
>> > [0]
>> > 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
>> >
>>
>> __________________________________________________________________________
>> 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
>
>
>
> __________________________________________________________________________
> 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
>