Re: [openstack-dev] [qa] Do I need a spec for testing the compute os-networks API?

[Matt Riedemann]

On 8/8/2014 9:50 AM, Andrea Frittoli wrote:

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.

andrea

[0] https://review.openstack.org/#/c/107552/21



On 8 August 2014 15:42, Matt Riedemann mailto:mrie...@linux.vnet.ibm.com>> 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] 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 





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



Andrea,

Thanks, the client stuff was what I needed right now since that was the 
bulk of the code I needed for this simple POC to show the bug:


https://review.openstack.org/#/c/112944/

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [qa] Do I need a spec for testing the compute os-networks API?

[Andrea Frittoli]

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.

andrea

[0] https://review.openstack.org/#/c/107552/21



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

[openstack-dev] [qa] Do I need a spec for testing the compute os-networks API?

[Matt Riedemann]

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