Neutron API-site: "Response parameters" of "List networks" missing some params

[Keiichiro Tokunaga]

"Response parameters" of "List networks" is missing the following parameters:

  - networks
  - mtu
  - port_security_enabled

Please see http://developer.openstack.org/api-ref-networking-v2-ext.html#listProviderNetworks .

Currently, "Response parameters" lists these params:

  - admin_state_up
    The administrative state of the network, which is up (true) or
    down (false).
  - id
    The network ID.
  - name
    The network name.
  - shared
    Indicates whether this network is shared across all tenants.
  - status
    The network status.
  - subnets
    The associated subnets.
  - tenant_id
    The tenant ID.
  - router:external
    Indicates whether this network is externally accessible.
  - mtu
    MTU of a network resource.
  - port_security_enabled
    The port security enablement status, which is enabled (true) or
    disabled (false).
  - provider:physical_network (Optional)
    The physical network where this network object is implemented.
    The Networking API v2.0 does not provide a way to list available
    physical networks. For example, the Open vSwitch plug-in configuration
    file defines a symbolic name that maps to specific bridges on each
    Compute host.
  - provider:network_type (Optional)
    The type of physical network that maps to this network resource.
    Examples are flat, vlan, vxlan, and gre.
  - provider:segmentation_id (Optional)
    An isolated segment on the physical network. The network_type
    attribute defines the segmentation model. For example, if the
    network_type value is vlan, this ID is a vlan identifier. If the
    network_type value is gre, this ID is a gre key.

Actual response is like this:

{
  "networks": [
    {
      "provider:segmentation_id": 1065,
      "id": "0d4af632-5e88-4d9a-a155-3f1a64a49986",
      "mtu": 0,
      "port_security_enabled": true,
      "shared": false,
      "status": "ACTIVE",
      "subnets": [
        "a0a928f1-e057-4ecd-99d6-659fe2c950c5",
        "a9d8ad08-71f9-4a7b-82f1-9005ff24e7c1"
      ],
      "name": "private4",
      "provider:physical_network": null,
      "router:external": false,
      "tenant_id": "56b048ae10a94b3893c3ac0b1cfb40a3",
      "admin_state_up": true,
      "provider:network_type": "vxlan"
    },
<sniped>

[Keiichiro Tokunaga (keiichiro)]

I rechecked the site again, and seems someone just added "mtu" and "port_security_enabled". I believe we still need to add "networks" to the table as it's actually in a response. In fact, some other sections are written in that manner. For example, "Response parameters" of "List security groups" has "security_groups". (See http://developer.openstack.org/api-ref-networking-v2-ext.html#listSecGroups .)

[Keiichiro Tokunaga (keiichiro)]

"Request parameters" and "Response parameters" of other methods in the same section (Networks provider extended attributes) are also missing "network". If core reviewers agree to add "network" or "networks" to the parameter tables, I'll post a patch to fix them all.

[Anne Gentle (annegentle)]

Thanks for the explanation, I think you're right.

[Keiichiro Tokunaga (keiichiro)]

Anne, thanks for confirming that. I'll post a patch then.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/209789

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/209789
Committed: https://git.openstack.org/cgit/openstack/api-site/commit/?id=5679efbc34d5a0da44dd3637d40c2b7dd439240c
Submitter: Jenkins
Branch: master

commit 5679efbc34d5a0da44dd3637d40c2b7dd439240c
Author: Keiichiro Tokunaga <email address hidden>
Date: Thu Aug 6 15:45:22 2015 +0900

    Add "network" and "networks" objects to Network v2.0 extensions

    "Request codes" and "response codes" tables of these
    sections are missing "network(s)" (xsd:dict).

      - Networks provider extended attributes
      - Networks multiple provider extension
      - VLAN transparency extension

    This patch adds it to all the tables. These sections
    refer to the same ENTITYs, so fixing the ENTITYs
    fixes all the sections. Having said that, I don't think
    it's a good idea that all list, create, show, and update
    operations use the same ENTITY, which is "networkListParameters"
    since that makes it harder to maintain the file. I split
    the ENTITY for each method individually, introducing a
    common ENTITY that other ENTITYs can refer to.

      - networkCommonResponseParams
      - networkListResponseParams
      - networkCreateReponseParams
      - networkShowResponseParams
      - networkUpdateResponseParams

    Change-Id: Ib969102eb509bf1096bb48f865885ed9542b84c8
    Closes-Bug: #1480312