Get the virtual network topology

> how many virtual devices such as vm, router, dhcp which connected to the network

You can port-list then filter by a network id.

> Further, we also want to know the tenants which those devices belong to

Once you have a list of ports, you can print out their tenant_id field.

> and the nodes on which those devices are located

That is persisted in the binding:host field.

Point is that all of this information may be found via a simple client script. What would a single command give you, and what would that command look like?

maybe the command looks like "neutron net-device-topology-list", we can get the count about routers, dhcp agents, instances which connect to every network. The command looks like "neutron net-device-topology-show net_id", we can get more details about devices which connect to the specified network. For every device ,we can know tenant_id, host node, zone, connect_port_id, subnet_id, ip_address

Can you describe the advantage of adding the functionality you're looking for over doing this client side via a script?

Adding a neutron API like this is very useful.
First, tenants can see the virtual network topology clearly and it contributes to understanding and planning network. Also ,it can reduce the requirement of the basic knowledge.
Second, for administrators , they can know how many devices connected to the network, and the details about every device, such as tenant_id, node, ip etc. So we can limit the number of instances in a network, also can know it whether supports dhcp ,floating-ip or not.
Third, it can simplify a lot of work for neutron developers. Don't need using nova command, such as "nova list", "nova interface-list" etc, we can know all information about network . If there are a ip which is unreachable, using neutron new API can search the network,instance, node, port about the ip directly. Just spend a little time on assuring the host node when we need to check the configuration environment or capture packets.

@dong-wenshuai, I have to say I'm still not clear what this new API would accomplish that a client side script would not. All of the information you detailed in comment 4 can be obtained via the current Neutron API. Can you give an example usage?

For example:
neutron net-device-topology-list
> Example output here

neutron net-device-topology-show net_id
> Example output here

I set up the bug so that we could discuss it in the next drivers team.

neutron net-device-topology-list:
network-id :net-id
network_name: net-name
instances: the count of instances which connect to the network
router : the count of router which connect to the network
free_port: the count of free ports

neutron net-device-topology-show net_id：
connected-devices-id : deivce_id,such as instance-id,router-id
type: device type,such as instance, router,qdhcp
zone: availability_zone
host-node: the host node at which the device located
tenant-id : tenant id of the device
link-port-id : port-id which connect to network
ip address: ip which connect to network
mac address: mac which connect to network

neutron net-device-topology-list:
+--------------------------------------+--------------+-----------+------------+------------+
| network-id | network_name | instances | router | free_port |
+--------------------------------------+--------------+-----------+------------+------------+
| 032428af-3f16-4352-89f7-56c33c6525c2 | test_net1 | 20 | 1 | 12 |
| 373729e6-59db-489b-baec-02db19c03a93 | test_net2 | 13 | 2 | 30 |
| 677dfc08-0c3f-4db0-a591-98c6cc71313e | test_net3 | 22 | 3 | 18 |
| aa40f2e5-08a4-403e-a8fe-0ab75cfedd14 | test_net4 | 14 | 2 | 0 |
| be5cb280-b4fd-415a-8665-cd2709c0aa7b | test_net5 | 9 | 1 | 21 |
+--------------------------------------+--------------+-----------+------------+------------+

neutron net-device-topology-show net_id：

+-----------------------+-------+-------+------------+--------------+----------------+--------------+-------------
| connected-devices-id | type | zone | host-node | tenant-id | link-port-id | ip address | mac address
+-----------------------+-------+-------+------------+--------------+----------------+--------------+-------------
| XXXXXXXXXXXXXXXXXXXXX | instance| nova | compute1 | XXXXXXXXXXX | XXXXXXXXXXXX | 192.168.1.8 | fa:16:3e:00:00:4e
| XXXXXXXXXXXXXXXXXXXXX | instance| cloud| compute3 | XXXXXXXXXXX | XXXXXXXXXXXX | 192.168.1.6 | fa:16:3e:00:00:23
| XXXXXXXXXXXXXXXXXXXXX | q-dhcp | - | dhcp-noe | XXXXXXXXXXX | XXXXXXXXXXXX | 192.168.1.2 | fa:16:3e:00:00:01
| | | | | | | 192.167.1.2 | fa:16:3e:00:00:a2
| XXXXXXXXXXXXXXXXXXXX | router | - | l3-node2 | XXXXXXXXXXX | XXXXXXXXXXXX | 192.168.1.1 | fa:16:3e:00:00:f2
| XXXXXXXXXXXXXXXXXXXX | router | - | l3-node3 | XXXXXXXXXXX | XXXXXXXXXXXX | 192.168.1.1 | fa:16:3e:00:00:e2
| | | | l3-node4 | | XXXXXXXXXXXX | |
+-----------------------+---------+------+----------+--------------+---------------+--------------+-------------

I see this class of requests as orchestration needs. You can provide a new API endpoint that builds all of this for you and expose it simply to the client, or implement it client side using the building blocks already at your disposal.

Both have pros and cons. If someone wanted to do this client side I would not be wildly opposed, but server side, I am a little more against it.

A good topic for drivers shedding

If adding this to the client (Which I think makes more sense, but I'm still not sold on), would this be added to the Neutron client, or the OpenStack client?

Most of the work can be done in openstack client side, but there are something need to do in server side .For example, querying "host" information from table "ml2_port_bindings" so that we can know the physical node of the device

Does the binding:host_id field under the Port model not work for this?

Sorry ,I ignore this before, all work can be done in openstack client side, not need to do anything in server side

This can be done entirely in the client side. It would essentially be a greppable, text based result similar to the current Horizon network diagram. New features belong to the openstack client, not the neutron client, so I fixed up the bug's target component.

http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2016-06-09.log.html#t2016-06-09T22:41:06

Is there a design that the OSC team can work off for this command proposal?

neutron net-device-topology-list:
network-id: get by command "net-list"
network_name: get by command "net-list"
instances: get by "port-list" and filter "net-id"
router : get the num of ports which device_owner start with "network:router"
free_port: get the num of ports which device_owner is None

neutron net-device-topology-show net_id：
connected-devices-id : get the port's device_id by command "port-list" and filter "net-id"
type: classify by port's device_owner
zone: classify by port's device_owner
host-node: can get from command "port-show"
tenant-id : can get from command "port-show" and "nova show"
link-port-id : port-id
ip address: can get from command "port-show"
mac address: can get from command "port-show"

Related fix proposed to branch: master
Review: https://review.openstack.org/338807

Reviewed: https://review.openstack.org/338807
Committed: https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=2a5ab357930a318800b6b15bd0a9f4ffd2c460d4
Submitter: Jenkins
Branch: master

commit 2a5ab357930a318800b6b15bd0a9f4ffd2c460d4
Author: dongwenshuai <email address hidden>
Date: Thu Jul 7 05:25:55 2016 -0400

    Add network-topolopy support

    Add a new api about network-topolopy in openstackclient
    It is the intention for OSC to collect data from existing
    REST APIs

    Change-Id: I23709ee906555d773c3efeb094aef50587732a1b
    Related-Bug: #1586584
    Implements: bp network-topology-support