Thanks Matt for bringing this up/

There is a tiny start in flight here [0] - if you plan to work on providing
full testing coverage for the n-net api you may want to create a spec with
a link to an etherpad to help track / split the work.



On 8 August 2014 15:42, Matt Riedemann <> wrote:

> 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]
> --
> Thanks,
> Matt Riedemann
> _______________________________________________
> OpenStack-dev mailing list
OpenStack-dev mailing list

Reply via email to