This came up while reviewing the fix for bug 1327406 [1]. Basically the os-networks API behaves differently depending on your backing network manager in nova-network.

We run Tempest in the gate with the FlatDHCPManager, which has the bug; if you try to list networks as a non-admin user it won't return anything you can't assign those networks to a tenant. With VlanManager you do assign a tenant so list-networks works.

I don't see any os-networks API testing in Tempest today and I'm looking to add something, at least for listing networks to show that this bug exists (plus get coverage). The question is do I need a qa-spec to do this? When I wrote the tests for os-quota-classes it was for a bug fix since we regressed when we thought the API was broken and unused and it was erroneously removed in Icehouse. I figured I'd treat this the same way, but it's going to require changes to the servers client to call the os-networks API, plus a new test module.

As far as the test design, we'd skip if using neutron since this is a nova-network only test. As far as how to figure out the proper assertions given we don't know what the backing network manager is and the API is inconsistent in that regard, I might have some other hurdles there but would at least like to get a POC going.

I guess I can do the POC before the question of blueprints/specs needs to be answered...

[1] https://launchpad.net/bugs/1327406

--

Thanks,

Matt Riedemann


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to