Open Stack

On Jun 14, 2014, at 9:12 AM, Mike Spreitzer <mspreitz at us.ibm.com> wrote:

> I am not even sure what is the intent, but some of the behavior looks like it is clearly unintended and not useful (a more precise formulation of "buggy" that is not defeated by the lack of documentation). 
> 
> IMHO, the API and CLI documentation should explain these calls/commands in enough detail that the reader can tell the difference.  And the difference should be useful in at least some networking configurations.  It seems to me that in some configurations an administrative user may want THREE varieties of the network listing call/command: one that shows networks assigned to his tenant, one that also shows networks available to be assigned, and one that shows all networks.  And in no configurations should a non-administrative user be blind to all categories of networks. 
> 
> In the API, there are the calls on /v2/{tenant_id}/os-networks and they are documented at http://docs.openstack.org/api/openstack-compute/2/content/ext-os-networks.html.  There are also calls on /v2/{tenant_id}/os-tenant-networks --- but I can not find documentation for them. 
> 
> http://docs.openstack.org/api/openstack-compute/2/content/ext-os-networks.html does not describe the meaning of the calls in much detail.  For example, about "GET /v2/{tenant_id}/os-networks" that doc says only "Lists networks that are available to the tenant".  In some networking configurations, there are two levels of availability: a network might be assigned to a tenant, or a network might be available for assignment.  In other networking configurations there are NOT two levels of availability.  For example, in Flat DHCP nova networking (which is the default in DevStack), a network CAN NOT be assigned to a tenant.

I think it should be returning the networks which a tenant will get for their instance when they launch it. This is unfortunately a bit confusing in vlan mode if a network has not been autoassigned, but that is generally a temporary case. So the bug fix below would lead to the correct behavior.

> 
> You might think that the "to the tenant" qualification implies filtering by the invoker's tenant.  But you would be wrong in the case of an administrative user; see the model_query method in nova/db/sqlalchemy/api.py 
> 
> In the CLI, we have two sets of similar-seeming commands.  For example, 
> 
> $ nova help net-list 
> usage: nova net-list 
> 
> List networks 
> 
> $ nova help network-list 
> usage: nova network-list 
> 
> Print a list of available networks. 

IMO net-list / os-tenant-networks should be deprecated because it really isn’t adding any features to the original extension.
> 
> Those remarks are even briefer than the one description in the API doc, omitting the qualification "to the tenant". 
> 
> Experimentation shows that, in the case of flat DHCP nova networking, both of those commands show zero networks to a non-administrative user (and remember that networks can not be assigned to tenants in that configuration) and all the networks to an administrative user.  At the API the GET calls behave the same way.  The fact that a non-administrative user sees zero networks looks unintended and not useful. 
> 
> See https://bugs.launchpad.net/openstack-manuals/+bug/1152862 and https://bugs.launchpad.net/nova/+bug/1327406 
> 
> Can anyone tell me why there are both /os-networks and /os-tenant-networks calls and what their intended semantics are? 

The os-networks extension (nova network-list, network-create, etc.) were originally designed to pull features from nova-manage network commands to allow administration of networks through the api instead of directly talking to the database. The os-tenant-networks extension (nova net-list) were initially created as a replacement for the above but they changed the semantics slightly so got turned into their own extension. Since then some work has been proposed to improve the original extension to add some functionality to os-networks and improve error handling[1]. The original extension not showing networks to tenants is a bug which you have already identified.

[1] https://review.openstack.org/#/c/93759/
> 
> Thanks,
> Mike_______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140701/8d1cc581/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140701/8d1cc581/attachment.pgp>