> On 28 Jun 2016, at 15:13, Hardik <[email protected]> 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
@Nokia

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to