Open Stack

Winson, Renat,

I think that it is a good idea. Moreover, it is relevant, because about a
month ago there was a question from one guy in our IRC channel about what
if some of other 3rd party systems which provide their own client bindings
(in python) want to integrate with Mistral, how it will work. For that
moment we just thought about it, but hadn't any blueprints or discussions.

Thanks,
Anastasia Kuznetsova
@ Mirantis Inc.


On Thu, Dec 18, 2014 at 9:33 AM, Renat Akhmerov <rakhmerov at mirantis.com>
wrote:
>
> Winson,
>
> The idea itself makes a lot of sense to me because we’ve had a number of
> discussions about how we could make action subsystem even more pluggable
> and flexible. One of the questions that we’d like to solve is to be able to
> add actions “on the fly” and at the same time stay safe. I think this whole
> thing is about specific technical details so I would like to see more of
> them. Generally speaking, you’re right about actions residing in a
> database, about 3 months ago we made this refactoring and put all actions
> into db but it may not be 100% necessary. Btw, we already have a concept of
> action generator that we use to automatically build OpenStack actions so
> you can take a look at how they work. Long story short… We’ve already made
> some steps towards being more flexible and have some facilities that could
> be further improved.
>
> Again, the idea is very interesting to me (and not only to me). Please
> share the details.
>
> Thanks
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
> > On 17 Dec 2014, at 13:22, W Chan <m4d.coder at gmail.com> wrote:
> >
> > Renat,
> >
> > We want to introduce the concept of an ActionProvider to Mistral.  We
> are thinking that with an ActionProvider, a third party system can extend
> Mistral with it's own action catalog and set of dedicated and specialized
> action executors.  The ActionProvider will return it's own list of actions
> via an abstract interface.  This minimizes the complexity and latency in
> managing and sync'ing the Action table.  In the DSL, we can define provider
> specific context/configuration separately and apply to all provider
> specific actions without explicitly passing as inputs.  WDYT?
> >
> > Winson
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20141219/39fead02/attachment.html>