[openstack-dev] [mistral] Test and Manage Openstack actions in Mistral

Renat Akhmerov renat.akhmerov at gmail.com
Tue Jun 28 08:29:37 UTC 2016

> On 28 Jun 2016, at 15:13, Hardik <hardik.parekh at nectechnologies.in> wrote:
> Hi folks,
> In Mistral, we face issues related managing openstack actions.
> Currently we have mapping.json file which should be updated manually using tools/get_actions_list.py.
> However, this script cannot be useful for neutron, zaqar, swift etc.
> Also, our unit test cases are not so efficient. So, I have following few suggestions.
> We should improve our tests in mistral/tests/unit/actions/openstack/test_generator.py and mistral/tests/unit/actions/test_action_manager.py. So that, we can assure that openstack actions are correctly registered to database with correct parameters.
Ok, agree. Those tests are now pretty poor.
> Also, we should install all supported openstack services  in our gates and we should have at least one functional test for each service.
Agree. I was thinking about not just one test per service but rather several tests that comprise a representative subset of certain service functionality.
> Improvement of get_actions_list.py. So that, it can generate actions for almost all openstack service.
Yeah, I wonder if we can use openstackclient instead of individual clients. Do think it’s possible? The bad thing about the current approach is that we should rely on different clients whereas not all of them are built in the same way. So we have to come up with certain tricks and it’s very volatile and hard to maintain.
> Also, I think we should get rid of mapping.json file (Don't know right now how) because its size will increase as we support more actions and it will become difficult to maintain this file. 
Ideally, yes, but the issue I see here is that actions must be registered in DB, this is how the whole model works. So we’ll have to migrate DB every time we detect some changes.
Regarding this, we discussed the idea of action providers long ago, [1]. It’s basically about moving away from having to store action definitions in DB. Instead we could register a number of providers and each of them could provide an interface to work with actions: get action, get list of them, etc. Maybe we need to resurrect this BP again when rebuilding action mechanism. 

Just one more note: keep in mind that we’re now revisiting all the approach around actions and a number of activities are going on, e.g. [2]. Eventually, these actions and tests for them will go into a different repository.

[1] https://blueprints.launchpad.net/mistral/+spec/mistral-action-providers <https://blueprints.launchpad.net/mistral/+spec/mistral-action-providers>
[2] https://review.openstack.org/#/c/325769/ <https://review.openstack.org/#/c/325769/>

Renat Akhmerov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160628/e55705b3/attachment.html>

More information about the OpenStack-dev mailing list