<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Jun 14, 2014, at 9:12 AM, Mike Spreitzer <<a href="mailto:mspreitz@us.ibm.com">mspreitz@us.ibm.com</a>> wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite"><font size="2" face="sans-serif">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).</font>
<br>
<br><font size="2" face="sans-serif">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.</font>
<br>
<br><font size="2" face="sans-serif">In the API, there are the calls on /v2/{tenant_id}/os-networks
and they are documented at </font><a href="http://docs.openstack.org/api/openstack-compute/2/content/ext-os-networks.html"><font size="2" face="sans-serif">http://docs.openstack.org/api/openstack-compute/2/content/ext-os-networks.html</font></a><font size="2" face="sans-serif">.
There are also calls on /v2/{tenant_id}/os-tenant-networks --- but
I can not find documentation for them.</font>
<br>
<br><a href="http://docs.openstack.org/api/openstack-compute/2/content/ext-os-networks.html"><font size="2" face="sans-serif">http://docs.openstack.org/api/openstack-compute/2/content/ext-os-networks.html</font></a><font size="2" face="sans-serif">
does not describe the meaning of the calls in much detail. For example,
about "GET /v2/{tenant_id}/os-networks" that doc says only "</font><font size="3">Lists
networks that are available to the tenant</font><font size="2" face="sans-serif">".
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.</font><br></blockquote><div><br></div>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.</div><div><br><blockquote type="cite">
<br><font size="2" face="sans-serif">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 </font>
<br>
<br><font size="2" face="sans-serif">In the CLI, we have two sets of similar-seeming
commands. For example,</font>
<br>
<br><tt><font size="2">$ nova help net-list</font></tt>
<br><tt><font size="2">usage: nova net-list</font></tt>
<br>
<br><tt><font size="2">List networks</font></tt>
<br>
<br><tt><font size="2">$ nova help network-list</font></tt>
<br><tt><font size="2">usage: nova network-list</font></tt>
<br>
<br><tt><font size="2">Print a list of available networks.</font></tt>
<br></blockquote><div><br></div>IMO net-list / os-tenant-networks should be deprecated because it really isn’t adding any features to the original extension.<br><blockquote type="cite">
<br><font size="2" face="sans-serif">Those remarks are even briefer than
the one description in the API doc, omitting the qualification "to
the tenant".</font>
<br>
<br><font size="2" face="sans-serif">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.</font>
<br>
<br><font size="2" face="sans-serif">See </font><a href="https://bugs.launchpad.net/openstack-manuals/+bug/1152862"><font size="2" face="sans-serif">https://bugs.launchpad.net/openstack-manuals/+bug/1152862</font></a><font size="2" face="sans-serif">
and </font><a href="https://bugs.launchpad.net/nova/+bug/1327406"><font size="2" face="sans-serif">https://bugs.launchpad.net/nova/+bug/1327406</font></a>
<br>
<br><font size="2" face="sans-serif">Can anyone tell me why there are both
/os-networks and /os-tenant-networks calls and what their intended semantics
are?</font>
<br></blockquote><div><br></div>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.<div><br></div><div>[1] <a href="https://review.openstack.org/#/c/93759/">https://review.openstack.org/#/c/93759/</a></div><blockquote type="cite">
<br><font size="2" face="sans-serif">Thanks,<br>
Mike</font>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></body></html>