<tt><font size=3>I am not even sure what is the intent, but some of the
behavior looks like <br>
it is clearly unintended and not useful (i.e., buggy).<br>
<br>
IMHO, the API and CLI documentation should explain these calls/commands
in <br>
enough detail that the reader can tell the difference.  And the difference
<br>
should be useful in at least some networking configurations.  It seems
to <br>
me that in some configurations an administrative user may want THREE <br>
varieties of the network listing call/command: one that shows networks
<br>
assigned to his tenant, one that also shows networks available to be <br>
assigned, and one that shows all networks.  And in no configurations
<br>
should a non-administrative user be blind to all categories of networks.<br>
<br>
In the API, there are the calls on /v2/{tenant_id}/os-networks and they
<br>
are documented at <br>
</font></tt><a href="http://docs.openstack.org/api/openstack-compute/2/content/ext-os-networks.html"><tt><font size=3 color=blue><u>http://docs.openstack.org/api/openstack-compute/2/content/ext-os-networks.html</u></font></tt></a><tt><font size=3><br>
.  There are also calls on /v2/{tenant_id}/os-tenant-networks ---
but I <br>
can not find documentation for them.<br>
<br>
</font></tt><a href="http://docs.openstack.org/api/openstack-compute/2/content/ext-os-networks.html"><tt><font size=3 color=blue><u>http://docs.openstack.org/api/openstack-compute/2/content/ext-os-networks.html</u></font></tt></a><tt><font size=3>
<br>
does not describe the meaning of the calls in much detail.  For example,
<br>
about "GET /v2/{tenant_id}/os-networks" that doc says only "Lists
networks <br>
that are available to the tenant".  In some networking configurations,
<br>
there are two levels of availability: a network might be assigned to a
<br>
tenant, or a network might be available for assignment.  In other
<br>
networking configurations there are NOT two levels of availability.  For
<br>
example, in Flat DHCP nova networking (which is the default in DevStack),
<br>
a network CAN NOT be assigned to a tenant.<br>
<br>
You might think that the "to the tenant" qualification implies
filtering <br>
by the invoker's tenant.  But you would be wrong in the case of an
<br>
administrative user; see the model_query method in <br>
nova/db/sqlalchemy/api.py <br>
<br>
In the CLI, we have two sets of similar-seeming commands.  For example,<br>
<br>
$ nova help net-list<br>
usage: nova net-list<br>
<br>
List networks<br>
<br>
$ nova help network-list<br>
usage: nova network-list<br>
<br>
Print a list of available networks.<br>
<br>
Those remarks are even briefer than the one description in the API doc,
<br>
omitting the qualification "to the tenant".<br>
<br>
Experimentation shows that, in the case of flat DHCP nova networking, both
<br>
of those commands show zero networks to a non-administrative user (and
<br>
remember that networks can not be assigned to tenants in that <br>
configuration) and all the networks to an administrative user.  At
the API <br>
the GET calls behave the same way.  The fact that a non-administrative
<br>
user sees zero networks looks unintended and not useful.<br>
<br>
See </font></tt><a href="https://bugs.launchpad.net/openstack-manuals/+bug/1152862"><tt><font size=3 color=blue><u>https://bugs.launchpad.net/openstack-manuals/+bug/1152862</u></font></tt></a><tt><font size=3>
and <br>
</font></tt><a href="https://bugs.launchpad.net/nova/+bug/1327406"><tt><font size=3 color=blue><u>https://bugs.launchpad.net/nova/+bug/1327406</u></font></tt></a><tt><font size=3><br>
<br>
Can anyone tell me why there are both /os-networks and /os-tenant-networks
<br>
calls and what their intended semantics are?<br>
<br>
Thanks,<br>
Mike</font></tt>