On Jun 14, 2014, at 9:12 AM, Mike Spreitzer <[email protected]> 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
> [email protected]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
