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.co...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
