Open Stack

On Mon, Sep 7, 2015 at 4:25 PM, Igor Kalnitsky <ikalnitsky at mirantis.com>
wrote:

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

yes that wired, by convention all LMA plugins have priorities well defined
between each other. It works well until we manage all related plugins but
reaches its limit for other plugins if we don't align them together.
This kind of workaround was the only solution at this time...


> 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.
>
> conditional tasks sounds good indeed, how can we bootstrap this feature?


> > 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.
>
> from POV of plugins development, priorities did the trick so far even if
it doesn't look like so natural..
I'm just speaking to provide/preserve the same flexibility within next
plugin framework releases.
If this effort can be made on the whole fuel internals and let plugins
enjoy it I would be happy.
do you have any pointers about these rumours, any BP ?

--
BR
Swann


> 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
> >
>
> __________________________________________________________________________
> 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/20150908/921c1a43/attachment.html>