Adds Networking API v2.0 specification files

Goal is to start maintaining API specs in the specs repos for each project
to eliminate maintenance of <project>-api repos.

Change-Id: I01faed48fa7ab8fd66c77d43f859d30ba4f66eb7
This commit is contained in:
Anne Gentle 2014-11-13 12:32:40 -06:00
parent 84461d1d95
commit eebdf8b039
22 changed files with 6643 additions and 0 deletions

View File

@ -22,6 +22,16 @@ Juno approved specs
specs/juno/*
API specs
=========
.. toctree::
:glob:
:maxdepth: 1
specs/api/*
Neutron Incubator
-----------------

View File

@ -0,0 +1,257 @@
================
Agent management
================
In a typical OpenStack Networking deployment, some agents run on network
or compute nodes, such as ``neutron-dhcp-agent``, ``neutron-ovs-agent``,
and ``neutron-l3-agent``. This extension enables administrators
(enforced by the policy engine) to view status and update attributes for
agents. Updating agent management API attributes affects operations of
other components, such as OpenStack Networking schedulers. For example,
administrators can disable a specified agent so that OpenStack
Networking schedulers do not schedule resources to it.
For how to use agent management extension and OpenStack Networking
schedulers feature, see the *OpenStack Cloud Administrator Guide*.
**GET** /agents Lists agents that report their status to Networking server.
**GET** /agents/*``agent_id``* Shows details for a specified agent.
**PUT** /agents/*``agent_id``* Updates the admin status and description for the agent.
**DELETE** /agents/*``agent_id``* Deletes a specified agent.
List agents
~~~~~~~~~~~
**GET** /agents
Lists agents that report their status to OpenStack Networking server.
Normal Response Code: 200
This operation does not require a request body.
This operation returns a response body. The default policy behavior is
that non-admin user won't be able to see any agent in the response when
this call is invoked
**Example List agents: JSON request**
.. code::
GET /v2.0/agents HTTP/1.1
Host: controlnode:9696
User-Agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: c52a1b304fec4ca0ac85dc1741eec6e2
**Example List agents: JSON response**
.. code::
{
"agents":[
{
"binary":"neutron-dhcp-agent",
"description":null,
"admin_state_up":false,
"heartbeat_timestamp":"2013-03-26T09:35:13.000000",
"alive":false,
"id":"af4567ad-c2e6-4311-944d-22efc12f89af",
"topic":"dhcp_agent",
"host":"HostC",
"agent_type":"DHCP agent",
"started_at":"2013-03-26T09:35:01.000000",
"created_at":"2013-03-26T09:35:01.000000",
"configurations":{
"subnets":2,
"use_namespaces":true,
"dhcp_driver":"neutron.agent.linux.dhcp.Dnsmasq",
"networks":2,
"dhcp_lease_time":120,
"ports":3
}
}
]
}
Show agent details
~~~~~~~~~~~~~~~~~~
**GET** /agents/*``agent_id``*
Shows details for a specified agent.
Normal Response Code: 200
Error Response Codes:NotFound (404) if not authorized or the agent does
not exist
This operation returns information for the given agent.
This operation does not require a request body.
This operation returns a response body. The body contents depend on the
agent's type.
**Example Show agent details: JSON request**
.. code::
GET /v2.0/agents/af4567ad-c2e6-4311-944d-22efc12f89af HTTP/1.1
Host: controlnode:9696
User-agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: a54d6fdda41341f892150e2aaf648f0d
**Example Show agent details: JSON response**
.. code::
{
"agent":{
"binary":"neutron-dhcp-agent",
"description":null,
"admin_state_up":false,
"heartbeat_timestamp":"2013-03-26T09:35:13.000000",
"alive":false,
"id":"af4567ad-c2e6-4311-944d-22efc12f89af",
"topic":"dhcp_agent",
"host":"HostC",
"agent_type":"DHCP agent",
"started_at":"2013-03-26T09:35:01.000000",
"created_at":"2013-03-26T09:35:01.000000",
"configurations":{
"subnets":2,
"use_namespaces":true,
"dhcp_driver":"neutron.agent.linux.dhcp.Dnsmasq",
"networks":2,
"dhcp_lease_time":120,
"ports":3
}
}
}
Update agent
~~~~~~~~~~~~
**PUT**
/agents/*``agent_id``*
Updates the admin status and description for a specified agent.
Normal Response Code: 200
Error Response Codes: BadRequest (400) if something other than
description or admin status is changed, NotFound (404) if not authorized
or the agent does not exist
This operation updates the agent's admin status and description.
This operation requires a request body.
This operation returns a response body.
**Example Update agent: JSON request**
.. code::
PUT /v2.0/agents/af4567ad-c2e6-4311-944d-22efc12f89af HTTP/1.1
Host: controlnode:9696
User-Agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: 4cbb09e780434b249ff596d6979fd8fc
Content-Length: 38{
"agent": {
"admin_state_up": "False"
}
}
**Example Update agents: JSON response**
.. code::
{
"agent":{
"binary":"neutron-dhcp-agent",
"description":null,
"admin_state_up":false,
"heartbeat_timestamp":"2013-03-26T09:35:13.000000",
"alive":false,
"id":"af4567ad-c2e6-4311-944d-22efc12f89af",
"topic":"dhcp_agent",
"host":"HostC",
"agent_type":"DHCP agent",
"started_at":"2013-03-26T09:35:01.000000",
"created_at":"2013-03-26T09:35:01.000000",
"configurations":{
"subnets":2,
"use_namespaces":true,
"dhcp_driver":"neutron.agent.linux.dhcp.Dnsmasq",
"networks":2,
"dhcp_lease_time":120,
"ports":3
}
}
}
Delete agent
~~~~~~~~~~~~
**DELETE**
/agents/*``agent_id``*
Deletes a specified agent.
Normal Response Code: 204
Error Response Codes: NotFound (404) if not authorized or the agent does
not exist
This operation deletes the agent.
This operation does not require a request body.
This operation does not return a response body.
**Example Delete agent: JSON request**
.. code::
DELETE /v2.0/agents/44002aeb-2817-4cb8-9306-34308b4b40d9 HTTP/1.1
Host: controlnode:9696
User-Agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: 4cbb09e780434b249ff596d6979fd8fc
**Example Delete agent: JSON response**
.. code::
HTTP/1.1 204 No Content
Content-Length: 0
Date: Tue, 26 Mar 2013 12:12:35 GMT

View File

@ -0,0 +1,600 @@
================
Agent schedulers
================
The agent scheduler extensions schedule resources among agents.
The agent scheduler feature consist of several agent scheduler
extensions. In Havana, the following extensions are available.
- DHCP agent scheduler (``dhcp_agent_scheduler``)
- L3 agent scheduler (``l3_agent_scheduler``)
- load balancer agent scheduler (``lbaas_agent_scheduler``)
In Grizzly, the DHCP agent scheduler and the L3 agent scheduler features
are provided by a single extension named the agent scheduler
(``agent_scheduler``). In Havana, this extension is split into the DHCP
agent scheduler and the L3 agent scheduler extensions. The load balancer
agent scheduler extension was introduced in Havana.
DHCP agent scheduler (``dhcp_agent_scheduler``)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The DHCP agent scheduler extension enables administrators to assign DHCP
servers for Neutron networks to given Neutron DHCP agents, and retrieve
mappings between Neutron networks and DHCP agents. This feature is
implemented on top of Agent Management extension.
**GET** /agents/*``agent_id``*/dhcp-networks
Lists networks that the specified DHCP agent hosts.
**GET** /networks/*``network_id``*/dhcp-agents
Lists DHCP agents that host a specified network.
**POST** /agents/*``agent_id``*/dhcp-networks
Schedules the network to that the specified DHCP agent.
**DELETE** /agents/*``agent_id``*/dhcp-networks/*``network_id``*
Removes the network from that the specified DHCP agent.
List networks hosted by a DHCP agent
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**GET** /agents/*``agent_id``*/dhcp-networks
Lists networks that the specified DHCP agenthosts.
Normal response Code: 200
Error response Codes: Unauthorized (401), Forbidden (403)
This operation does not require a request body.
This operation returns a response body.
**Example List networks hosted by on DHCP agent: JSON request**
.. code::
GET /v2.0/agents/d5724d7e-389d-4ba0-8d00-fc673a147bfa/dhcp-networks HTTP/1.1
Host: localhost:9696
User-Agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: 797f94caf0a8481c893a232cc0c1dfca
**Example List networks hosted by DHCP agent: JSON response**
.. code::
{
"networks":[
{
"status":"ACTIVE",
"subnets":[
"15a09f6c-87a5-4d14-b2cf-03d97cd4b456"
],
"name":"net1",
"provider:physical_network":"physnet1",
"admin_state_up":true,
"tenant_id":"3671f46ec35e4bbca6ef92ab7975e463",
"provider:network_type":"vlan",
"router:external":false,
"shared":false,
"id":"2d627131-c841-4e3a-ace6-f2dd75773b6d",
"provider:segmentation_id":1001
},
{
"status":"ACTIVE",
"subnets":[
],
"name":"net2",
"provider:physical_network":null,
"admin_state_up":true,
"tenant_id":"3671f46ec35e4bbca6ef92ab7975e463",
"provider:network_type":"local",
"router:external":false,
"shared":false,
"id":"524e26ea-fad4-4bb0-b504-1ad0dc770e7a",
"provider:segmentation_id":null
},
{
"status":"ACTIVE",
"subnets":[
"43671fba-c76b-4c33-bd7e-8bef54145f2f"
],
"name":"mynet1",
"provider:physical_network":"physnet1",
"admin_state_up":true,
"tenant_id":"3671f46ec35e4bbca6ef92ab7975e463",
"provider:network_type":"vlan",
"router:external":false,
"shared":false,
"id":"cfa65a54-06a8-4f9f-86b0-73c700c02c41",
"provider:segmentation_id":1000
}
]
}
List DHCP agents hosted by network
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**GET** /networks/*``network_id``*/dhcp-agents
Lists DHCP agents that hosts a specified network.
Normal response Code: 200
Error response Codes: Unauthorized (401), Forbidden (403)
This operation does not require a request body.
This operation returns a response body.
**Example List DHCP agents hosted by network: JSON request**
.. code::
GET /v2.0/networks/2d627131-c841-4e3a-ace6-f2dd75773b6d/dhcp-agents HTTP/1.1
Host: localhost:9696
User-Agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: cc0f378bdf1545fb8dea2120c89eb532
**Example List DHCP agents hosted by network: JSON response**
.. code::
{
"agents":[
{
"binary":"neutron-dhcp-agent",
"description":null,
"admin_state_up":true,
"heartbeat_timestamp":"2013-03-27T00:24:01.000000",
"alive":false,
"topic":"dhcp_agent",
"host":"HostC",
"agent_type":"DHCP agent",
"created_at":"2013-03-26T23:54:20.000000",
"started_at":"2013-03-26T23:54:20.000000",
"id":"d5724d7e-389d-4ba0-8d00-fc673a147bfa",
"configurations":{
"subnets":2,
"use_namespaces":true,
"dhcp_driver":"neutron.agent.linux.dhcp.Dnsmasq",
"networks":2,
"dhcp_lease_time":120,
"ports":5
}
}
]
}
Schedule network to DHCP agent
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**POST** /agents/*``agent_id``*/dhcp-networks
Schedules the network to that the specified DHCP agent.
Normal response Code: 201
Error response Codes: Unauthorized (401), Forbidden (403), Conflict
(409) if the network is already hosted by that the specified DHCP agent,
NotFound(404) when the specified agent is not a valid DHCP agent.
This operation requires a request body.
This operation returns a ``null`` body.
**Example Schedule network: JSON request**
.. code::
POST /v2.0/agents/d5724d7e-389d-4ba0-8d00-fc673a147bfa/dhcp-networks.json HTTP/1.1
Host: localhost:9696
User-Agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: d88f7af21ee34f6c87e23e46cf3f986d
Content-Length: 54
{"network_id": "1ae075ca-708b-4e66-b4a7-b7698632f05f"}
**Example Schedule network: JSON response**
.. code::
HTTP/1.1 201 Created
Content-Type: application/json; charset=UTF-8
Content-Length: 4
Date: Wed, 27 Mar 2013 01:22:46 GMT
null
Remove network from DHCP agent
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**DELETE** /agents/*``agent_id``*/dhcp-networks/*``network_id``*
Removes the network from that the specified DHCP agent.
Normal response Code: 204
Error response Codes: Unauthorized (401), Forbidden (403), NotFound
(404), Conflict (409) if the network is not hosted by that the specified
DHCP agent.
This operation does not require a request body.
This operation does not return a response body.
**Example Remove network from DHCP agent: JSON request**
.. code::
DELETE /v2.0/agents/d5724d7e-389d-4ba0-8d00-fc673a147bfa/dhcp-networks/1ae075ca-708b-4e66-b4a7-b7698632f05f.json HTTP/1.1
Host: localhost:9696
User-Agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: 7ae91cde8f504031be5a2cd5b99d4fe9
L3 agent scheduler (``l3_agent_scheduler``)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The L3 agent scheduler extension allows administrators to assign Neutron
routers to Neutron L3 agents, and retrieve mappings between Neutron
routers and L3 agents. This feature is implemented on top of Agent
Management extension.
**GET** /agents/*``agent_id``*/l3-routers
Lists routers that the specified L3 agent hosts.
**GET** /routers/*``router_id``*/l3-agents
Lists L3 agents that hosts a specified router.
**POST** /agents/*``agent_id``*/l3-routers
Schedules the router to that the specified L3 agent.
**DELETE** /agents/*``agent_id``*/l3-routers/*``router_id``*
Removes the router from that the specified L3 agent.
List routers hosted by an L3 agent
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**GET** /agents/*``agent_id``*/l3-routers
Lists routers that the specified L3 agent hosts.
Normal response Code: 200
Error response Codes: Unauthorized (401), Forbidden (403)
This operation does not require a request body.
This operation returns a response body.
**Example List routers hosted by L3 agent: JSON request**
.. code::
GET /v2.0/agents/fa24e88e-3d2f-4fc2-b038-5fb5be294c03/l3-routers.json HTTP/1.1
Host: localhost:9696
User-Agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: 6eeea6e73b68415f85d8368902a32c11
**Example List routers hosted by L3 agent: JSON response**
.. code::
{
"routers":[
{
"status":"ACTIVE",
"external_gateway_info":null,
"name":"router1",
"admin_state_up":true,
"tenant_id":"3671f46ec35e4bbca6ef92ab7975e463",
"routes":[
],
"id":"8eef2388-f27d-4a17-986e-9319a77ccd9d"
}
]
}
List L3 agents hosted by router
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**GET** /routers/*``router_id``*/l3-agents
Lists L3 agents that hosts a specified router.
Normal response Code: 200
Error response Codes: Unauthorized (401), Forbidden (403)
This operation does not require a request body.
This operation returns a response body.
**Example List L3 agents hosted by router: JSON request**
.. code::
GET /v2.0/routers/8eef2388-f27d-4a17-986e-9319a77ccd9d/l3-agents.json HTTP/1.1
Host: localhost:9696
User-Agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: bce63afb1e794c70972a19a7c2d6dcab
**Example List L3 agents hosted by router: JSON response**
.. code::
{
"agents":[
{
"binary":"neutron-l3-agent",
"description":null,
"admin_state_up":true,
"heartbeat_timestamp":"2013-03-27T00:24:03.000000",
"alive":false,
"topic":"l3_agent",
"host":"HostC",
"agent_type":"L3 agent",
"created_at":"2013-03-26T23:54:26.000000",
"started_at":"2013-03-26T23:54:26.000000",
"id":"fa24e88e-3d2f-4fc2-b038-5fb5be294c03",
"configurations":{
"router_id":"",
"gateway_external_network_id":"",
"handle_internal_only_routers":true,
"use_namespaces":true,
"routers":0,
"interfaces":0,
"floating_ips":0,
"interface_driver":"neutron.agent.linux.interface.OVSInterfaceDriver",
"ex_gw_ports":0
}
}
]
}
Schedule router to L3 agent
^^^^^^^^^^^^^^^^^^^^^^^^^^^
**POST** /agents/*``agent_id``*/l3-routers
Schedules one router to that the specified L3 agent.
Normal response Code: 201
Error response Codes: Unauthorized (401), Forbidden (403), Conflict
(409) if the router is already hosted, NotFound (404) if the specified
agent is not a valid L3 agent.
This operation requires a request body.
This operation returns a ``null`` body.
**Example Schedule router: JSON request**
.. code::
POST /v2.0/agents/fa24e88e-3d2f-4fc2-b038-5fb5be294c03/l3-routers.json HTTP/1.1
Host: localhost:9696
User-Agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: d88f7af21ee34f6c87e23e46cf3f986d
Content-Length: 54
{"router_id": "8eef2388-f27d-4a17-986e-9319a77ccd9d"}
**Example Schedule router: JSON response**
.. code::
HTTP/1.1 201 Created
Content-Type: application/json; charset=UTF-8
Content-Length: 4
Date: Wed, 27 Mar 2013 01:22:46 GMT
null
Remove router from L3 agent
^^^^^^^^^^^^^^^^^^^^^^^^^^^
**DELETE** /agents/*``agent_id``*/l3-routers/*``network_id``*
Removes the router from that the specified L3 agent.
Normal response Code: 204
Error response Codes: Unauthorized (401), Forbidden (403), Conflict
(409) if the router is not hosted by that the specified L3 agent.
This operation does not require a request body.
This operation does not return a response body.
**Example Remove router from L3 agent: JSON request**
.. code::
DELETE /v2.0/agents/b7d7ba43-1a05-4b09-ba07-67242d4a98f4/l3-routers/8eef2388-f27d-4a17-986e-9319a77ccd9d.json HTTP/1.1
Host: localhost:9696
User-Agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: 2147ef6fe4444f0299b1c0b6b529ff47
Load balancer agent scheduler (``lbaas_agent_scheduler``)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The LBaaS agent scheduler extension allows administrators to retrieve
mappings between load balancer pools to LBaaS agents. In Havana, this
extension does not provide an ability to assign load balancer pool to
specific LBaaS agent. Pools are scheduled automatically when created.
This feature is implemented on top of Agent Management extension. The
load balancer agent scheduler extension was introduced in Havana.
**GET** /agents/*``agent_id``*/loadbalancer-pools
Lists pools that the specified LBaaS agent hosts.
**GET** /lb/pools/*``pool_id``*/loadbalancer-agent
Shows an LBaaS agent that hosts a specified pool.
List pools hosted by an LBaaS agent
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**GET** /agents/*``agent_id``*/loadbalancer-pools
Lists pools that the specified LBaaS agent hosts.
Normal response Code: 200
Error response Codes: Unauthorized (401), Forbidden (403)
This operation does not require a request body.
This operation returns a response body.
**Example List pools hosted by LBaaS agent: JSON request**
.. code::
GET /v2.0/agents/6ee1df7f-bae4-4ee9-910a-d33b000773b0/loadbalancer-pools.json HTTP/1.1
Host: localhost:9696
User-Agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: 6eeea6e73b68415f85d8368902a32c11
**Example List pools hosted by LBaaS agent: JSON response**
.. code::
{
"pools": [
{
"admin_state_up": true,
"description": "",
"health_monitors": [],
"health_monitors_status": [],
"id": "28296abb-e675-4288-9cd0-6c112c720db0",
"lb_method": "ROUND_ROBIN",
"members": [],
"name": "pool1",
"protocol": "HTTP",
"provider": "haproxy",
"status": "PENDING_CREATE",
"status_description": null,
"subnet_id": "f8fd83d3-2080-4ab9-9814-391fe7b8a7a4",
"tenant_id": "54d7b6253c8c4e64862fbd08b3fc08cd",
"vip_id": null
}
]
}
Show LBaaS agent that hosts pool
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**GET** /lb/pools/*``pool_id``*/loadbalancer-agent
Shows an LBaaS agent that hosts a specified pool.
Normal response Code: 200
Error response Codes: Unauthorized (401), Forbidden (403)
This operation does not require a request body.
This operation returns a response body.
**Example Show LBaaS agent that hosts pool: JSON request**
.. code::
GET /v2.0/lb/pools/28296abb-e675-4288-9cd0-6c112c720db0/loadbalancer-agent.json HTTP/1.1
Host: localhost:9696
User-Agent: python-neutronclient
Content-Type: application/json
Accept: application/json
X-Auth-Token: bce63afb1e794c70972a19a7c2d6dcab
**Example Show LBaaS agent that hosts pool: JSON response**
.. code::
{
"agent": {
"admin_state_up": true,
"agent_type": "Loadbalancer agent",
"alive": true,
"binary": "neutron-loadbalancer-agent",
"configurations": {
"device_driver": "neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver",
"devices": 0,
"interface_driver": "neutron.agent.linux.interface.OVSInterfaceDriver"
},
"created_at": "2013-10-01 12:50:13",
"description": null,
"heartbeat_timestamp": "2013-10-01 12:56:29",
"host": "ostack02",
"id": "6ee1df7f-bae4-4ee9-910a-d33b000773b0",
"started_at": "2013-10-01 12:50:13",
"topic": "lbaas_process_on_host_agent"
}
}

View File

@ -0,0 +1,252 @@
=====================
Allowed address pairs
=====================
The allowed address pair extension extends the port attribute to enable
you to specify arbitrary mac\_address/ip\_address(cidr) pairs that are
allowed to pass through a port regardless of the subnet associated with
the network.
List ports
~~~~~~~~~~
**GET** /ports
Lists ports with their allowed address pair attributes.
Normal Response Code: 200 OK
Error Response Codes: 401 Unauthorized
This operation returns, for each port, its allowed address pair
attributes as well as all the attributes normally returned by the list
port operation.
**Example List ports with allowed address pair attributes: JSON
response**
.. code::
{
"ports":[
{
"admin_state_up": true,
"allowed_address_pairs": [{"ip_address": "23.23.23.1",
"mac_address": "fa:16:3e:c4:cd:3f"}],
"device_id": "",
"device_owner": "",
"fixed_ips": [{"ip_address": "10.0.0.2",
"subnet_id": "f4145134-b99b-4b18-9940-47239f071923"}],
"id": "191f5290-3a5a-40ff-b0cb-cd4b115b400e",
"mac_address": "fa:16:3e:c4:cd:3f",
"name": "",
"network_id": "327f2a2f-9d70-417f-ac3a-d3155e25cf25",
"status": "DOWN",
"tenant_id": "8462a4d167f84256b7035f4c408c1185"
},
{
"admin_state_up": true,
"allowed_address_pairs": [],
"device_id": "",
"device_owner": "",
"fixed_ips": [{"ip_address": "10.0.0.3",
"subnet_id": "f4145134-b99b-4b18-9940-47239f071923"}],
"id": "ec2fb9f9-a11b-4791-852d-eb1ab9b27a0e",
"mac_address": "fa:16:3e:a9:3e:1a",
"name": "",
"network_id": "327f2a2f-9d70-417f-ac3a-d3155e25cf25",
"status": "DOWN",
"tenant_id": "8462a4d167f84256b7035f4c408c1185"
}
]
}
**Example List ports with allowed address pair attributes: XML
response**
.. code::
<?xml version='1.0' encoding='UTF-8'?>
<ports xmlns="http://openstack.org/quantum/api/v2.0"
xmlns:quantum="http://openstack.org/quantum/api/v2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<port>
<status>ACTIVE</status>
<name/>
<allowed_address_pairs>
<allowed_address_pair>
<ip_address>23.23.23.1</ip_address>
<mac_address>fa:16:3e:c4:cd:3f</mac_address>
</allowed_address_pair>
</allowed_address_pairs>
<admin_state_up quantum:type="bool">True</admin_state_up>
<network_id>3537e809-8bec-4ae4-a5ab-2c6477760195</network_id>
<tenant_id>8462a4d167f84256b7035f4c408c1185</tenant_id>
<device_owner/>
<mac_address>fa:16:3e:21:4c:2e</mac_address>
<fixed_ips>
<fixed_ip>
<subnet_id>f4145134-b99b-4b18-9940-47239f071923</subnet_id>
<ip_address>10.0.0.21</ip_address>
</fixed_ip>
</fixed_ips>
<id>191f5290-3a5a-40ff-b0cb-cd4b115b400e</id>
<device_id/>
</port>
<port>
<status>ACTIVE</status>
<name/>
<allowed_address_pairs xsi:nil="true"/>
<admin_state_up quantum:type="bool">True</admin_state_up>
<network_id>327f2a2f-9d70-417f-ac3a-d3155e25cf25</network_id>
<tenant_id>8462a4d167f84256b7035f4c408c1185</tenant_id>
<device_owner/>
<mac_address>fa:16:3e:a9:3e:1a</mac_address>
<fixed_ips>
<fixed_ip>
<subnet_id>18cf6972-95cc-4134-a986-843dc7433aa0</subnet_id>
<ip_address>10.0.0.5</ip_address>
</fixed_ip>
</fixed_ips>
<id>ec2fb9f9-a11b-4791-852d-eb1ab9b27a0e</id>
<device_id/>
</port>
</ports>
Show port details
~~~~~~~~~~~~~~~~~
**GET** /ports/*``port_id``*
Shows details about a specified port, including allowed address pair
attributes.
Normal Response Code: 200 OK
Error Response Code: 401 Unauthorized, 404 Not Found
**Example Show port with allowed address pair attributes: JSON
response**
.. code::
{
"port":
{
"admin_state_up": true,
"allowed_address_pairs": [{"ip_address": "23.23.23.1",
"mac_address": "fa:16:3e:c4:cd:3f"}],
"device_id": "",
"device_owner": "",
"fixed_ips": [{"ip_address": "10.0.0.2",
"subnet_id": "f4145134-b99b-4b18-9940-47239f071923"}],
"id": "191f5290-3a5a-40ff-b0cb-cd4b115b400e",
"mac_address": "fa:16:3e:c4:cd:3f",
"name": "",
"network_id": "327f2a2f-9d70-417f-ac3a-d3155e25cf25",
"status": "DOWN",
"tenant_id": "8462a4d167f84256b7035f4c408c1185"
}
}
**Example Show port with allowed address pair attributes: XML
response**
.. code::
<?xml version='1.0' encoding='UTF-8'?>
<port xmlns="http://openstack.org/quantum/api/v2.0"
xmlns:quantum="http://openstack.org/quantum/api/v2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<status>ACTIVE</status>
<name />
<allowed_address_pairs>
<allowed_address_pair>
<ip_address>23.23.23.1</ip_address>
<mac_address>fa:16:3e:c4:cd:3f</mac_address>
</allowed_address_pair>
</allowed_address_pairs>
<admin_state_up quantum:type="bool">True</admin_state_up>
<network_id>3537e809-8bec-4ae4-a5ab-2c6477760195</network_id>
<tenant_id>8462a4d167f84256b7035f4c408c1185</tenant_id>
<device_owner />
<mac_address>fa:16:3e:21:4c:2e</mac_address>
<fixed_ips>
<fixed_ip>
<subnet_id>f4145134-b99b-4b18-9940-47239f071923</subnet_id>
<ip_address>10.0.0.21</ip_address>
</fixed_ip>
</fixed_ips>
<id>191f5290-3a5a-40ff-b0cb-cd4b115b400e</id>
<device_id />
</port>
Create port
~~~~~~~~~~~
**POST** /ports
Creates a port and explicitly specifies the allowed address pair
attributes.
Normal Response Code: 201
Error Response Code: 400 Bad Request, 401 Unauthorized, 403 Forbidden
Bad request is returned if an allowed address pair matches the
mac\_address and ip\_address on port.
Note: If the mac\_address field is left out of the body of the request
the mac\_address assigned to the port will be used.
**Example Create port with allowed address pair attributes: JSON
request**
.. code::
{
"port":
{
"network_id": "3537e809-8bec-4ae4-a5ab-2c6477760195",
"allowed_address_pairs": [{"ip_address": "10.3.3.3"}]
}
}
Update port
~~~~~~~~~~~
**PUT** /ports/*``port_id``*
Updates a port, with new allowed address pair values.
Normal Response Code: 200 OK
Error Response Code: 400 Bad Request, 401 Unauthorized, 404 Not Found,
403 Forbidden
**Example Update allowed address pair attributes for a port: JSON
request**
.. code::
{
"port": {
"allowed_address_pairs":
[
{"ip_address": "10.0.0.1"}
]
}
}

View File

@ -0,0 +1,337 @@
===================================
Configurable external gateway modes
===================================
By default, when a gateway is attached to a router using the Neutron L3
extension, Network Address Translation (NAT) is enabled for traffic
generated by subnets attached to the router. With this extension, the
user will have the option of choosing whether SNAT should be enabled or
not on a router basis.
This is achieved simply by specifying a boolean attribute,
``enable_snat``, in the ``external_gateway_info`` attribute of the
``router`` resource.
This extension redefines the external\_gateway\_info attribute:
**Table external\_gateway\_info attributes**
============ ======= ======== ============= ================================
Attribute Type Required Default Value Validation Constraints and Notes
============ ======= ======== ============= ================================
network\_id UUID Yes N/A Must be a valid uuid representative
of an external network.
enable\_snat Boolean No True {True\|False}
The default setting is ``True`` to
ensure backward compatibility for
plugins supporting this extension.
============ ======= ======== ============= ================================
SNAT can be enabled or disabled at any time on a Neutron router
regardless of the current status of floating IPs. Floating IPs will
continue working even when SNAT is disabled.
List routers
~~~~~~~~~~~~
**GET** /routers
Lists neutron routers.
Success and error response codes are not changed with regards to the
operation as introduced by the L3 API extension.
When this extension is enabled, this operation also returns the current
Source NAT status for configured routers, as follows.
The response for the *show router* operation is the same, with the
obvious exception that a single router is returned.
**Example Router list with configurable external gateway modes
enabled**
.. code::
{
"routers":
[{
"status": "ACTIVE",
"external_gateway_info":
{"network_id": "3c5bcddd-6af9-4e6b-9c3e-c153e521cab8",
"enable_snat": true},
"name": "second_router",
"admin_state_up": true,
"tenant_id": "6b96ff0cb17a4b859e1e575d221683d3",
"id": "7177abc4-5ae9-4bb7-b0d4-89e94a4abf3b"
},
{
"status": "ACTIVE",
"external_gateway_info":
{"network_id": "3c5bcddd-6af9-4e6b-9c3e-c153e521cab8",
"enable_snat": false},
"name": "router1",
"admin_state_up": true,
"tenant_id": "33a40233088643acb66ff6eb0ebea679",
"id": "a9254bdb-2613-4a13-ac4c-adc581fba50d"
}]
}
Create router with external gateway
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
**POST** /routers
Create a new Neutron router
Success and error response codes are not changed with regards to the
operation as introduced by the L3 API extension.
Neutron API users can specify whether SNAT should be performed on the
network specified as the router's external gateway by setting
``enable_snat`` in ``external_gateway_info`` to either ``True`` or
``False``; the default value is ``True``.
**Example Create router with SNAT disabled**
.. code::
POST /v2.0/routers
Accept: application/json
{
"router":
{
"name": "another_router",
"admin_state_up": true,
"external_gateway_info": {
"network_id": "3c5bcddd-6af9-4e6b-9c3e-c153e521cab8",
"enable_snat": false}
}
}
HTTP/1.1 201 OK
Content-Type: application/json; charset=UTF-8
{
"router":
{
"status": "ACTIVE",
"external_gateway_info": {
"network_id": "3c5bcddd-6af9-4e6b-9c3e-c153e521cab8",
"enable_snat": false}
"name": "another_router",
"admin_state_up": true,
"tenant_id": "6b96ff0cb17a4b859e1e575d221683d3",
"id": "8604a0de-7f6b-409a-a47c-a1cc7bc77b2e"
}
}
Update external gateway information for router
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
**PUT** /routers/``router_id``
Creates a neutron router.
Success and error response codes are not changed with regards to the
operation as introduced by the L3 API extension.
Neutron API users can enable or disable SNAT on a router specifying the
``enable_snat`` attribute in the ``external_gateway_info`` attribute for
the router resource. This operation can be either used for updating the
SNAT status only, the external network, or both attributes at the same
time. In any case, if the ``enable_snat`` attribute is not specified, it
will default to ``True``. For instance, if the current SNAT status is
disabled, and the router's gateway is updated to a different external
network without specifying ``enable_snat``, SNAT will be enabled for the
new network.
It is important to note that whenever updating a router's external
gateway information, the ``network_id``\ parameter must be specified
always, even if the final goal is just to enable or disable SNAT for the
router on the same external network.
The rest of this section provides some samples for updating a router's
external gateway info with SNAT mode.
**Example Disable SNAT for the current external network**
.. code::
{
"router":
{
"name": "another_router",
"admin_state_up": true,
"external_gateway_info": {
"network_id": "3c5bcddd-6af9-4e6b-9c3e-c153e521cab8"}
}
}
.. code::
{
"router":{
"status":"ACTIVE",
"external_gateway_info":{
"network_id":"3c5bcddd-6af9-4e6b-9c3e-c153e521cab8",
"enable_snat":true
},
"name":"another_router",
"admin_state_up":true,
"tenant_id":"6b96ff0cb17a4b859e1e575d221683d3",
"id":"8604a0de-7f6b-409a-a47c-a1cc7bc77b2e"
}
}
.. code::
{
"router":{
"status":"ACTIVE",
"external_gateway_info":{
"network_id":"3c5bcddd-6af9-4e6b-9c3e-c153e521cab8",
"enable_snat":false
},
"name":"another_router",
"admin_state_up":true,
"tenant_id":"6b96ff0cb17a4b859e1e575d221683d3",
"id":"8604a0de-7f6b-409a-a47c-a1cc7bc77b2e"
}
}
.. code::
{
"router":{
"external_gateway_info":{
"network_id":"3c5bcddd-6af9-4e6b-9c3e-c153e521cab8",
"enable_snat":false
}
}
}
**Example Change external network and enable SNAT**
.. code::
{
"router":
{
"name": "another_router",
"admin_state_up": true,
"external_gateway_info": {
"network_id": "3c5bcddd-6af9-4e6b-9c3e-c153e521cab8",
"enable_snat": false}
}
}
.. code::
{
"router":
{
"status": "ACTIVE",
"external_gateway_info": {
"network_id": "3c5bcddd-6af9-4e6b-9c3e-c153e521cab8",
"enable_snat": false},
"name": "another_router",
"admin_state_up": true,
"tenant_id": "6b96ff0cb17a4b859e1e575d221683d3",
"id": "8604a0de-7f6b-409a-a47c-a1cc7bc77b2e"
}
}
.. code::
{
"router":
{
"external_gateway_info": {
"network_id": "002ab3b9-9127-4158-be30-4b45f3814df5"}
}
}
.. code::
{
"router":
{
"status": "ACTIVE",
"external_gateway_info": {
"network_id": "002ab3b9-9127-4158-be30-4b45f3814df5",
"enable_snat": true},
"name": "another_router",
"admin_state_up": true,
"tenant_id": "6b96ff0cb17a4b859e1e575d221683d3",
"id": "8604a0de-7f6b-409a-a47c-a1cc7bc77b2e"
}
}
**Example Change external network and external-gateway SNAT
disabled**
.. code::
{
"router":
{
"name": "another_router",
"admin_state_up": true,
"external_gateway_info": {
"network_id": "3c5bcddd-6af9-4e6b-9c3e-c153e521cab8",
"enable_snat": false}
}
}
.. code::
{
"router":
{
"status": "ACTIVE",
"external_gateway_info": {
"network_id": "3c5bcddd-6af9-4e6b-9c3e-c153e521cab8",
"enable_snat": false},
"name": "another_router",
"admin_state_up": true,
"tenant_id": "6b96ff0cb17a4b859e1e575d221683d3",
"id": "8604a0de-7f6b-409a-a47c-a1cc7bc77b2e"
}
}
.. code::
{
"router":
{
"external_gateway_info": {
"network_id": "002ab3b9-9127-4158-be30-4b45f3814df5",
"enable_snat": false}
}
}
.. code::
{
"router":
{
"status": "ACTIVE",
"external_gateway_info": {
"network_id": "002ab3b9-9127-4158-be30-4b45f3814df5",
"enable_snat": false},
"name": "another_router",
"admin_state_up": true,
"tenant_id": "6b96ff0cb17a4b859e1e575d221683d3",
"id": "8604a0de-7f6b-409a-a47c-a1cc7bc77b2e"
}
}

View File

@ -0,0 +1,166 @@
================================
External networks (external-net)
================================
The external network extension is used to specify whether the network is
external or not. This information is used by Layer-3 network
(``router``) extension. External networks are connected to a router's
external gateway and host floating IPs.
The external network extension adds the router:external attribute to the
network resource.
CRUD\ `:sup:`[a]` <#ftn.crud_ext_net>`__
router:external type:Bool Not required, Default: False
Specifies whether the network is an external network or not.
- **`:sup:`[a]` <#crud_ext_net>`__\ C**. Use the attribute in create
operations.
- **R**. This attribute is returned in response to show and list
operations.
- **U**. You can update the value of this attribute.
- **D**. You can delete the value of this attribute.
List networks
~~~~~~~~~~~~~
**GET** /networks
Returns a list of networks with their router:external attributes.
Response codes are same as the normal operation of listing networks.
router:external attribute is visible to all users by default policy
setting.
Regular users are not authorized to create ports on external networks,
however they will be able to see this attribute in their network list.
This is because external networks can be used by any tenant to set an
external gateway for Neutron routers or create floating IPs and
associate them with ports on internal tenant networks.
**Example List networks with router:external attribute: JSON
response**
.. code::
{
"networks": [
{
"admin_state_up": true,
"id": "0f38d5ad-10a6-428f-a5fc-825cfe0f1970",
"name": "net1",
"router:external": false,
"shared": false,
"status": "ACTIVE",
"subnets": [
"25778974-48a8-46e7-8998-9dc8c70d2f06"
],
"tenant_id": "b575417a6c444a6eb5cc3a58eb4f714a"
},
{
"admin_state_up": true,
"id": "8d05a1b1-297a-46ca-8974-17debf51ca3c",
"name": "ext_net",
"router:external": true,
"shared": false,
"status": "ACTIVE",
"subnets": [
"2f1fb918-9b0e-4bf9-9a50-6cebbb4db2c5"
],
"tenant_id": "5eb8995cf717462c9df8d1edfa498010"
}
]
}
Show network details
~~~~~~~~~~~~~~~~~~~~
**GET** /networks/*``network_id``*
Returns details about a specific network, including external networks
attributes.
Response codes are same as the normal operation of listing networks.
router:external attribute is visible to all users including non-admin by
default policy setting.
**Example Show network with external attributes: JSON response**
.. code::
{
"network": {
"admin_state_up": true,
"id": "8d05a1b1-297a-46ca-8974-17debf51ca3c",
"name": "ext_net",
"router:external": true,
"shared": false,
"status": "ACTIVE",
"subnets": [
"2f1fb918-9b0e-4bf9-9a50-6cebbb4db2c5"
],
"tenant_id": "5eb8995cf717462c9df8d1edfa498010"
}
}
Create network
~~~~~~~~~~~~~~
**POST** /networks
Creates a new network using the external network extension attribute.
If the user submitting the request is not allowed to set this attribute,
a 403 Forbidden response will be returned. Usage of this attribute might
be restricted through authorization policies. By the default policy only
admin users can set this attribute.
**Example 4.40. Create network with external attributes: JSON request**
.. code::
{
"network": {
"admin_state_up": true,
"name": "ext_net",
"router:external": true
}
}
Update network
~~~~~~~~~~~~~~
**PUT** /networks/*``network_id``*
Updates a network, including the external network extension attribute.
If the user submitting the request is not allowed to set this attribute,
a 403 Forbidden response will be returned. Usage of this attribute might
be restricted through authorization policies. By the default policy only
admin users can set this attribute.
**Example Update external attributes for a network: JSON request**
.. code::
{
"network":{
"router:external":true
}
}

View File

@ -0,0 +1,282 @@
===================================
Extra DHCP options (extra-dhcp-opt)
===================================
The DHCP options extension allows adding DHCP options that are
associated to a Neutron port. They are tagged such that they can be
associated from the hosts file to designate a specific network interface
and port. The DHCP tag scheme used to associate options to the host
files is the port\_id (UUID - in the form of ``8-4-4-4-12`` for a total
of 36 characters), these associate options to a Neutron port and its
network. The Dynamic Host Configuration Protocol (DHCP) provides a
framework for passing configuration information to hosts on a TCP/IP
network. Configuration parameters and other information are carried in
tagged data items that are stored in the 'options' field of the DHCP
message.
You can specify a DHCP options when defining or updating a port by
specifying the extra\_dhcp\_opts tag and providing its options as name
value pairs, such as, opt\_name='bootfile-name',
opt\_value='pxelinux.0'.
Concepts
~~~~~~~~
The ``extra-dhcp-opt`` extension is an attribute extension which adds
the following set of attributes to the **port** resource:
- extra-dhcp-opt:opt\_name - Specified the DHCP option that this is
defined as mapped to this port resource. Examples are
``bootfile-name``, ``server-ip-address``, ``tftp-server``, etc..
- extra-dhcp-opt:opt\_value - Identifies the value associated with the
opt\_name. These are handled in opt\_name, opt\_value pairs only.
value\_opt can be any text string depending upon the name.
The actual semantics of ``extra-dhcp-opt`` attributes depend on the name
of the dhcp option being used that defines the vendor extension to DHCP.
For example reference RFC: http://tools.ietf.org/html/rfc2132, contains
specific detail on BOOTP Vendor Extensions.
List ports
~~~~~~~~~~
**GET** /ports
Lists ports with attributes.
Normal response Code: 200 OK
Error response Codes: 401 Unauthorized
This operation returns all the ports defined in Neutron that to which
this user has access.
**Example List ports with extra\_dhcp\_opts: JSON response**
.. code::
{
"ports": [
{
"status": "DOWN",
"binding:host_id": null,
"name": "",
"allowed_address_pairs": [],
"admin_state_up": true,
"network_id": "87733bcc-8144-41b1-bb6b-d011d7a5168e",
"tenant_id": "7ea98790cd854fb5a82ef3d41e5c156b",
"extra_dhcp_opts": [{"opt_value": "testfile.1", "opt_name": "bootfile-name"}, {"opt_value": "123.123.123.45", "opt_name": "server-ip-address"}, {"opt_value": "123.123.123.123", "opt_name": "tftp-server"}],
"binding:vif_type": "ovs",
"device_owner": "",
"binding:capabilities": {"port_filter": true},
"mac_address": "fa:16:3e:52:92:3a",
"fixed_ips": [{"subnet_id": "99a8aea3-b9da-409d-a5e5-f45338ceb4d3", "ip_address": "172.24.4.228"}],
"id": "3c0c7a37-690a-43a8-8088-5d4c2c7f8484",
"security_groups": ["9bf6f19a-ba4a-470f-b8ce-28c9ad66556c"],
"device_id": ""
},
{
"status": "ACTIVE",
"binding:host_id": null,
"name": "",
"allowed_address_pairs": [],
"admin_state_up": true,
"network_id": "87733bcc-8144-41b1-bb6b-d011d7a5168e",
"tenant_id": "7ea98790cd854fb5a82ef3d41e5c156b",
"extra_dhcp_opts": [],
"binding:vif_type": "ovs",
"device_owner": "compute:probe",
"binding:capabilities": {"port_filter": true},
"mac_address": "fa:16:3e:49:56:07",
"fixed_ips": [{"subnet_id": "99a8aea3-b9da-409d-a5e5-f45338ceb4d3", "ip_address": "172.24.4.227"}],
"id": "5212d40a-c2f5-4a5d-ad18-694658047654",
"security_groups": ["9bf6f19a-ba4a-470f-b8ce-28c9ad66556c"],
"device_id": "zvm2"
}
]
}
Show port details
~~~~~~~~~~~~~~~~~
**GET** /ports/*``port_id``*
Shows details about a specified port, including ``extra-dhcp-opt``
attributes.
Normal response Code: 200 OK
Error response Code: 401 Unauthorized, 404 Not Found
This operation returns, for the port specified in the request URI, its
port attributes, including the extra\_dhcp\_opts attributes.
**Example Show port details with extra-dhcp-opt attributes: JSON
response**
.. code::
{
"port":
{
"status": "DOWN",
"binding:host_id": null,
"name": "",
"allowed_address_pairs": [],
"admin_state_up": true,
"network_id": "87733bcc-8144-41b1-bb6b-d011d7a5168e",
"tenant_id": "7ea98790cd854fb5a82ef3d41e5c156b",
"extra_dhcp_opts": [
{"opt_value": "testfile.1","opt_name": "bootfile-name"},
{"opt_value": "123.123.123.123", "opt_name": "tftp-server"},
{"opt_value": "123.123.123.45", "opt_name": "server-ip-address"}
],
"binding:vif_type": "ovs",
"device_owner": "",
"binding:capabilities": {"port_filter": true},
"mac_address": "fa:16:3e:52:92:3a",
"fixed_ips": [{"subnet_id": "99a8aea3-b9da-409d-a5e5-f45338ceb4d3", "ip_address": "172.24.4.228"}],
"id": "3c0c7a37-690a-43a8-8088-5d4c2c7f8484",
"security_groups": ["9bf6f19a-ba4a-470f-b8ce-28c9ad66556c"],
"device_id": ""
}
}
Create port
~~~~~~~~~~~
**POST** /ports
Creates a port and explicitly specifies attributes with the
``extra-dhcp-opt`` extension attributes.
Normal response Code: 200 OK
Error response Code: 401 Unauthorized.
This operation returns, for the port specified in the request URI, its
port attributes, including the extra\_dhcp\_opts attributes.
**Example Create port with extra-dhcp-opt attributes: JSON
request**
.. code::
{
"port":
{
"network_id": "87733bcc-8144-41b1-bb6b-d011d7a5168e",
"extra_dhcp_opts": [
{"opt_value": "pxelinux.0", "opt_name": "bootfile-name"},
{"opt_value": "123.123.123.123", "opt_name": "tftp-server"},
{"opt_value": "123.123.123.45", "opt_name": "server-ip-address"}
],
"fixed_ips": [{"subnet_id": "99a8aea3-b9da-409d-a5e5-f45338ceb4d3", "ip_address": "172.24.4.230"}],
"admin_state_up": true
}
}
**Example Create port with extra-dhcp-opt attributes: JSON
response**
.. code::
{
"port":
{
"status": "DOWN",
"binding:host_id": null,
"name": "",
"allowed_address_pairs": [],
"admin_state_up": true,
"network_id": "87733bcc-8144-41b1-bb6b-d011d7a5168e",
"tenant_id": "7ea98790cd854fb5a82ef3d41e5c156b",
"extra_dhcp_opts": [
{"opt_value": "123.123.123.123", "opt_name": "tftp-server"},
{"opt_value": "pxelinux.0", "opt_name": "bootfile-name"},
{"opt_value": "123.123.123.45", "opt_name": "server-ip-address"}
],
"binding:vif_type": "ovs",
"device_owner": "",
"binding:capabilities": {"port_filter": true},
"mac_address": "fa:16:3e:43:3c:b7",
"fixed_ips": [{"subnet_id": "99a8aea3-b9da-409d-a5e5-f45338ceb4d3", "ip_address": "172.24.4.230"}],
"id": "055d27c0-0194-4782-be45-275ff2c95c61",
"security_groups": ["9bf6f19a-ba4a-470f-b8ce-28c9ad66556c"],
"device_id": ""
}
}
Update port
~~~~~~~~~~~
**PUT** /ports/*``port_id``*
Updates attributes for a port, including extra\_dhcp\_opts extension
attributes.
Normal response Code: 200 OK
Error response Code: 401 Unauthorized.
This operation allow for the updating of attributes for the port
specified in the request URI, its port attributes, including the
extra\_dhcp\_opts attributes.
**Example Update port with extra-dhcp-opt attributes: JSON
request**
.. code::
{
"port":
{
"extra_dhcp_opts": [{"opt_value": "testfile.1", "opt_name": "bootfile-name"}]
}
}
**Example Update port with extra-dhcp-opt attributes: JSON
response**
.. code::
{
"port":
{
"status": "DOWN",
"binding:host_id": null,
"name": "",
"allowed_address_pairs": [],
"admin_state_up": true,
"network_id": "87733bcc-8144-41b1-bb6b-d011d7a5168e",
"tenant_id": "7ea98790cd854fb5a82ef3d41e5c156b",
"extra_dhcp_opts":
[
{"opt_value": "123.123.123.123", "opt_name": "tftp-server"},
{"opt_value": "testfile.1", "opt_name": "bootfile-name"},
{"opt_value": "123.123.123.45", "opt_name": "server-ip-address"}
],
"binding:vif_type": "ovs",
"device_owner": "",
"binding:capabilities": {"port_filter": true},
"mac_address": "fa:16:3e:43:3c:b7",
"fixed_ips": [{"subnet_id": "99a8aea3-b9da-409d-a5e5-f45338ceb4d3", "ip_address": "172.24.4.230"}],
"id": "055d27c0-0194-4782-be45-275ff2c95c61",
"security_groups": ["9bf6f19a-ba4a-470f-b8ce-28c9ad66556c"],
"device_id": ""
}
}

112
specs/api/extra_routes.rst Normal file
View File

@ -0,0 +1,112 @@
============
Extra routes
============
This extension adds extra routes to the ``router`` resource.
You can specify a set of nexthop IPs and destination CIDRs.
Note
~~~~
The nexthop IP must be a part of one of the subnets to which the router
interfaces are connected. You can configure the ``routes`` attribute on
only update operations.
**Table Router attributes**
Attribute
Type
Required
CRUD\ `:sup:`[a]` <#ftn.crud_extraroute>`__
Default Value
Validation Constraints
Notes
routes
list of dict
No
U
None
List should be in this form. [{'nexthop':IPAddress, 'destination':CIDR}]
Extra route configuration
- **`:sup:`[a]` <#crud_extraroute>`__\ C**. Use the attribute in create
operations.
- **R**. This attribute is returned in response to show and list
operations.
- **U**. You can update the value of this attribute.
- **D**. You can delete the value of this attribute.
Update extra route
~~~~~~~~~~~~~~~~~~
**PUT**
/routers/*``router_id``*
Updates logical router with ``routes`` attribute.
Normal Response Code: 200
Error Response Codes: Unauthorized (401), Bad Request (400), Not Found
(404), Conflict (409)
This operation configures extra routes on the router. The nexthop IP
must be a part of one of the subnets to which the router interfaces are
connected. Otherwise, the server responds with ``400 Bad Request`` error
code. When a validation error is detected, such as a format error of IP
address or CIDR, the server responds with ``400 Bad Request``. When
Networking receives a request to delete the router interface for subnets
that are used by one or more routes, it responds with ``409 Conflict``.
**Example Update routes: JSON request**
.. code::
{
"router":{
"routes":[
{
"nexthop":"10.1.0.10",
"destination":"40.0.1.0/24"
}
]
}
}
**Example Update routes: JSON response**
.. code::
{"router":
{"status": "ACTIVE",
"external_gateway_info": {"network_id": "5c26e0bb-a9a9-429c-9703-5c417a221096"},
"name": "router1",
"admin_state_up": true,
"tenant_id": "936fa220b2c24a87af51026439af7a3e",
"routes": [{"nexthop": "10.1.0.10", "destination": "40.0.1.0/24"}],
"id": "babc8173-46f6-4b6f-8b95-38c1683a4e22"}
}

File diff suppressed because it is too large Load Diff

View File

@ -0,0 +1,54 @@
===========================
Layer-3 networking (router)
===========================
The Layer-3 networking extension enables OpenStack Networking API users
to route packets between subnets, forward packets from internal networks
to external ones, and access instances from external networks through
floating IPs.
The OpenStack Networking Layer-3 extension defines these resources:
- **router**. A logical entity that forwards packets across internal
subnets and NATs them on external networks through an appropriate
external gateway. A router has an interface for each subnet with which it is
associated. By default, the IP address of such interface is the
subnet's gateway IP. Also, whenever a router is associated with a
subnet, a port for that router interface is added to the subnet's
network.
- **floating IP**. Represents an external IP address that is mapped to
an OpenStack Networking port and, optionally, a specific IP address
on a private OpenStack Networking network. A floating IP enables
access to an instance on a private network from an external network.
Floating IPs can only be defined on networks where the
router:external attribute (by the external network extension) is set
to ``True``.
.. csv-table:: Router attributes
:header: "Attribute", "Type", "Required", "CRUD", "Default value", "Validation constraints", "Notes"
:widths: 18, 4, 3, 4, 4, 4, 30
"id", "uuid-str", "N/A", "R", "generated", "N/A", "Unique identifier for the router."
"name", "String", "No", "CRU", "None", "N/A", "Human readable name for the router. Does not have to be unique."
"admin\_state\_up", "Bool", "No", "CRU", "true", "{true\false}", "Administrative state of the router."
"status", "String", "N/A", "R", "N/A", "N/A", "Indicates whether or not a router is currently operational."
"tenant\_id", "uuid-str", "No", "CR", "Derived from Authentication token", "N/A", "Owner of the router. Only admin users can specify a tenant identifier
other than its own."
"external\_gateway\_info", "dict", "No", "CRU", "None", "No constraint", "Information on external gateway for the router."
.. csv-table:: Floating IP attributes
:header: "Attribute", "Type", "Required", "CRUD", "Default value", "Validation constraints", "Notes"
:widths: 18, 4, 3, 4, 4, 4, 30
"id", "uuid-str", "N/A", "R", "generated", "N/A", "Unique identifier for the floating IP instance."
"floating_network_id", "uuid-str", "Yes", "CR", "N/A", "UUID Pattern", "UUID of the external network where the floating IP is to be created."
"port_id", "uuid-str", "Yes", "CRU", "N/A", "UUID Pattern", "UUID of the port on an internal OpenStack Networking network which should be associated to the floating IP."
"fixed_ip_address", "IP Address", "No", "CRU", "None", "IP address or null", "Specific IP address on port_id which should be associated with the floating IP."
"floating_ip_address", "IP Address", "N/A", "R", "Address of the floating IP on the external network."
"tenant\_id", "uuid-str", "No", "CR", "Derived from Authentication token", "N/A", "Owner of the floating IP. Only admin users can specify a tenant identifier other than its own."
..note:
C means, use the attribute in create operations. R means this attribute is
returned in response to show and list operations. U means you can update the
value of this attribute. D means you can delete the value of this attribute.

View File

@ -0,0 +1,148 @@
==================================
Load-Balancer-as-a-Service (LBaaS)
==================================
The LBaaS extension enables OpenStack tenants to load-balance their VM
traffic.
The extension enables you to:
- Load-balance client traffic from one network to application services,
such as VMs, on the same or a different network.
- Load-balance several protocols, such as TCP and HTTP.
- Monitor the health of application services.
- Support session persistence.
Concepts
~~~~~~~~
This extension introduces these concepts:
Load balancers
The primary load-balancing configuration object. Specifies the
virtual IP address where client traffic is received.
Pools
A logical set of devices, such as web servers, that you group
together to receive and process traffic.
The load-balancing algorithm chooses which member of the pool
handles new requests or connections that are received on a listener.
Each listener has one default pool.
Listener
Represents a single listening port. Defines the protocol and can
optionally provide TLS termination.
Members
The application that runs on the back-end server.
Health monitors
Determines whether or not back-end members of the pool can process a
request. A pool can have one health monitor associated with it.
The LBaaS extension supports these types of health monitors:
- **PING**. Uses ICMP to ping the members.
- **TCP**. Uses TCP to connect to the members.
- **HTTP**. Sends an HTTP request to the member.
- **HTTPS**. Sends a secure HTTP request to the member.
Session persistence
Forces connections or requests in the same session to be processed
by the same member as long as it is active.
The LBaaS extension supports these types of persistence:
- **SOURCE\_IP**. All connections that originate from the same
source IP address are handled by the same member of the pool.
- **HTTP\_COOKIE**. The load-balancing function creates a cookie on
the first request from a client. Subsequent requests that contain
the same cookie value are handled by the same member of the pool.
- **APP\_COOKIE**. The load-balancing function relies on a cookie
established by the back-end application. All requests with the
same cookie value are handled by the same member of the pool.
Absence of ``session_persistence`` attribute means no session
persistence mechanism is used.
When no session persistence is used, the ``session_persistence``
attribute does not appear in the API response and instead returns
null.
You can clear session persistence by sending ``null`` in
``session_persistence`` attribute in a listener update request.
Use the LBaaS extension to configure load balancing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You must complete these high-level tasks:
**To use the LBaaS extension to configure load balancing**
#. Create a pool, which is initially empty.
#. Create one or more members in the pool.
#. Create a health monitor.
#. Associate the health monitor with the pool.
#. Create a load balancer object.
#. Create a listener.
#. Associate the listener with the load balancer.
#. Associate the pool with the listener.
#. Optional. If you use HTTPS termination, complete these tasks:
#. Add the TLS certificate, key, and optional chain to Barbican.
#. Associate the Barbican container with the listener.
#. Optional. If you use layer-7 HTTP switching, complete these tasks:
#. Create any additional pools, members, and health monitors that are
used as non-default pools.
#. Create a layer-7 policy that associates the listener with the
non-default pool.
#. Create rules for the layer-7 policy that describe the logic that
selects the non-default pool for servicing some requests.
Load balancers
~~~~~~~~~~~~~~
Use the LBaaS extension to create and manage load balancers.
Listeners
~~~~~~~~~
Use the LBaaS extension to create and manage load-balancer listeners.
Pools
~~~~~
Use the LBaaS extension to create and manage load-balancer pools.
Members
~~~~~~~
Use the LBaaS extension to create and manage load-balancer pool members.
Health monitors
~~~~~~~~~~~~~~~
Use the LBaaS extension to create and manage load-balancer health
monitors.

View File

@ -0,0 +1,6 @@
=========================
Metering labels and rules
=========================
Create, modify, and delete OpenStack Layer3 metering labels and rules.

View File

@ -0,0 +1,6 @@
==========================
Multiple provider networks
==========================
Set and retrieve the multiple provider networks extension attributes for
network objects.

View File

@ -0,0 +1,190 @@
============================
Networking API v2.0 Overview
============================
The Neutron project provides virtual networking services among devices
that are managed by the
`OpenStack <http://wiki.openstack.org/OpenStack>`__ compute service.
The Networking API v2.0 combines the `Quantum API
v1.1 <http://docs.openstack.org/api/openstack-network/1.0/content/>`__
with some essential Internet Protocol Address Management (IPAM)
capabilities from the `Melange
API <http://melange.readthedocs.org/en/latest/apidoc.html>`__.
These IPAM capabilities enable you to:
- Associate IP address blocks and other network configuration settings
required by a network device, such as a default gateway and
dns-servers settings, with an OpenStack Networking network.
- Allocate an IP address from a block and associate it with a device
that is attached to the network through an OpenStack Networking port.
To do this, the Networking API v2.0 introduces the subnet entity. A
subnet can represent either an IP version 4 or version 6 address block.
Each OpenStack Networking network commonly has one or more subnets. When
you create a port on the network, an available fixed IP address is
allocated to it from one the designated subnets for each IP version.
When you delete the port, the allocated addresses return to the pool of
available IPs on the subnet. Networking API v2.0 users can choose a
specific IP address from the block or let OpenStack Networking choose
the first available IP address.
Note
~~~~
The Quantum API v1.\ ``x`` was removed from the source code tree. To use
the Quantum API v1.\ ``x``, install the Quantum Essex release.
Concepts
--------
Use the Networking API v2.0 to manage the following entities:
- **Network**. An isolated virtual layer-2 domain. A network can also
be a virtual, or logical, switch.
- **Subnet**. An IP version 4 or version 6 address block from which IP
addresses that are assigned to VMs on a specified network are
selected.
- **Port**. A virtual, or logical, switch port on a specified network.
These entities have auto-generated unique identifiers and support basic
create, read, update, and delete (CRUD) functions with the **POST**,
**GET**, **PUT**, and **DELETE** verbs.
Network
~~~~~~~
A network is an isolated virtual layer-2 broadcast domain that is
typically reserved for the tenant who created it unless you configure
the network to be shared. Tenants can create multiple networks until the
thresholds per-tenant quota is reached.
In the Networking API v2.0, the network is the main entity. Ports and
subnets are always associated with a network.
The following table describes the attributes for network objects:
Subnet
~~~~~~
A subnet represents an IP address block that can be used to assign IP
addresses to virtual instances. Each subnet must have a CIDR and must be
associated with a network. IPs can be either selected from the whole
subnet CIDR or from allocation pools that can be specified by the user.
A subnet can also optionally have a gateway, a list of dns name servers,
and host routes. This information is pushed to instances whose
interfaces are associated with the subnet.
Port
~~~~
A port represents a virtual switch port on a logical network switch.
Virtual instances attach their interfaces into ports. The logical port
also defines the MAC address and the IP address(es) to be assigned to
the interfaces plugged into them. When IP addresses are associated to a
port, this also implies the port is associated with a subnet, as the IP
address was taken from the allocation pool for a specific subnet.
**Table Port Attributes**
High-level task flow
--------------------
The high-level task flow for OpenStack Networking involves creating a
network, associating a subnet with that network, and booting a VM that
is attached to the network. Clean-up includes deleting the VM, deleting
any ports associated with the network, and deleting the networks.
OpenStack Networking deletes any subnets associated with the deleted
network.
**To use OpenStack Networking - high-level task flow**
#. **Create a network**
The tenant creates a network.
For example, the tenant creates the ``net1`` network. Its ID is
net1\_id.
#. **Associate a subnet with the network**
The tenant associates a subnet with that network.
For example, the tenant associates the ``10.0.0.0/24`` subnet with
the ``net1`` network.
#. **Boot a VM and attach it to the network**
The tenant boots a virtual machine (VM) and specifies a single NIC
that connects to the network.
The following examples use the nova client to boot a VM.
In the first example, Nova contacts OpenStack Networking to create
the NIC and attach it to the ``net1`` network, with the ID net1\_id:
.. code::
$ nova boot <server_name> --image <image> --flavor <flavor> --nic net-id=<net1_id>
In a second example, you first create the ``port1``, port and then
you boot the VM with a specified port. OpenStack Networking creates a
NIC and attaches it to the ``port1`` port, with the ID port1\_id:
.. code::
$ nova boot <server_name> --image <image> --flavor <flavor> --nic port-id=<port1_id>
OpenStack Networking chooses and assigns an IP address to the
``port1`` port.
For more information about the **nova boot** command, enter:
.. code::
$ nova help boot
#. **Delete the VM**
The tenant deletes the VM.
Nova contacts OpenStack Networking and deletes the ``port1`` port.
The allocated IP address is returned to the pool of available IP
addresses.
#. **Delete any ports**
If the tenant created any ports and associated them with the network,
the tenant deletes the ports.
#. **Delete the network**
The tenant deletes the network. This operation deletes an OpenStack
Networking network and its associated subnets provided that no port
is currently configured on the network.
Plug-ins
--------
Virtual networking services are implemented through a plug-in. A plug-in
can use different techniques and technologies to provide isolated
virtual networks to tenants. A plug-in also provides other services,
such as IP address management. Because each plug-in implements all the
operations included in Networking API v2.0, do not be concerned about
which plug-in is used.
However, some plug-ins might expose additional capabilities through API
extensions, which this document discusses. For more information about
the extensions exposed by a particular plug-in, see the plug-in
documentation.

View File

@ -0,0 +1,533 @@
=======================================
Networking API v2.0 general information
=======================================
The Networking API v2.0 is a ReSTful HTTP service that uses all aspects
of the HTTP protocol including methods, URIs, media types, response
codes, and so on. Providers can use existing features of the protocol
including caching, persistent connections, and content compression. For
example, providers who employ a caching layer can respond with a 203
code instead of a 200 code when a request is served from the cache.
Additionally, providers can offer support for conditional **GET**
requests by using ETags, or they may send a redirect in response to a
**GET** request. Create clients so that these differences are accounted
for.
Authentication and authorization
--------------------------------
The Networking API v2.0 uses the OpenStack Identity
service <https://docs.openstack.org/developer/keystone>`__ as the default
authentication service. When Keystone is enabled, users that submit
requests to the OpenStack Networking service must provide an
authentication token in **X-Auth-Token** request header. You obtain the
token by authenticating to the Keystone endpoint.
When Keystone is enabled, the ``tenant_id`` attribute is not required in
create requests because the tenant ID is derived from the authentication
token.
The default authorization settings allow only administrative users to
create resources on behalf of a different tenant.
OpenStack Networking uses information received from Keystone to
authorize user requests. OpenStack Networking handles the following
types of authorization policies:
- **Operation-based policies** specify access criteria for specific
operations, possibly with fine-grained control over specific
attributes.
- **Resource-based policies** access a specific resource. Permissions
might or might not be granted depending on the permissions configured
for the resource. Currently available for only the network resource.
The actual authorization policies enforced in OpenStack Networking might
vary from deployment to deployment.
Request and response formats
----------------------------
The Networking API v2.0 supports both JSON and XML data serialization
request and response formats.
Request format
~~~~~~~~~~~~~~
Use the ``Content-Type`` request header to specify the request format.
This header is required for operations that have a request body.
The syntax for the ``Content-Type`` header is:
.. code::
Content-Type: application/FORMAT
Where *``FORMAT``* is either ``json`` or ``xml``.
Response format
~~~~~~~~~~~~~~~
Use one of the following methods to specify the response format:
``Accept`` header
The syntax for the ``Accept`` header is:
.. code::
Accept: application/FORMAT
Where *``FORMAT``* is either ``json`` or ``xml``. The default format
is ``json``.
Query extension
Add an ``.xml`` or ``.json`` extension to the request URI. For
example, the ``.xml`` extension in the following list networks URI
request specifies that the response body is to be returned in XML
format:
**GET** *``publicURL``*/networks.xml
If you do not specify a response format, JSON is the default.
If the ``Accept`` header and the query extension specify conflicting
formats, the format specified in the query extension takes precedence.
For example, if the query extension is ``.xml`` and the ``Accept``
header specifies ``application/json``, the response is returned in XML
format.
You can serialize a response in a different format from the request
format.
Filtering and column selection
------------------------------
The Networking API v2.0 supports filtering based on all top level
attributes of a resource. Filters are applicable to all list requests.
For example, the following request returns all networks named
``foobar``:
.. code::
GET /v2.0/networks?name=foobar
When you specify multiple filters, the Networking API v2.0 returns only
objects that meet all filtering criteria. The operation applies an AND
condition among the filters.
Note
~~~~
OpenStack Networking does not offer an OR mechanism for filters.
Alternatively, you can issue a distinct request for each filter and
build a response set from the received responses on the client-side.
By default, OpenStack Networking returns all attributes for any show or
list call. The Networking API v2.0 has a mechanism to limit the set of
attributes returned. For example, return ``id``.
You can use the ``fields`` query parameter to control the attributes
returned from the Networking API v2.0.
For example, the following request returns only ``id`` and ``name`` for
each network:
.. code::
GET /v2.0/networks.json?fields=id&fields=name
Synchronous versus asynchronous plug-in behavior
------------------------------------------------
The Networking API v2.0 presents a logical model of network connectivity
consisting of networks, ports, and subnets. It is up to the OpenStack
Networking plug-in to communicate with the underlying infrastructure to
ensure packet forwarding is consistent with the logical model. A plug-in
might perform these operations asynchronously.
When an API client modifies the logical model by issuing an HTTP
**POST**, **PUT**, or **DELETE** request, the API call might return
before the plug-in modifies underlying virtual and physical switching
devices. However, an API client is guaranteed that all subsequent API
calls properly reflect the changed logical model.
For example, if a client issues an HTTP **PUT** request to set the
attachment for a port, there is no guarantee that packets sent by the
interface named in the attachment are forwarded immediately when the
HTTP call returns. However, it is guaranteed that a subsequent HTTP
**GET** request to view the attachment on that port returns the new
attachment value.
You can use the ``status`` attribute with the network and port resources
to determine whether the OpenStack Networking plug-in has successfully
completed the configuration of the resource.
Bulk-create
-----------
The Networking API v2.0 enables you to create several objects of the
same type in the same API request. Bulk create operations use exactly
the same API syntax as single create operations except that you specify
a list of objects rather than a single object in the request body.
Bulk operations are always performed atomically, meaning that either all
or none of the objects in the request body are created. If a particular
plug-in does not support atomic operations, the Networking API v2.0
emulates the atomic behavior so that users can expect the same behavior
regardless of the particular plug-in running in the background.
OpenStack Networking might be deployed without support for bulk
operations and when the client attempts a bulk create operation, a 400
Bad request error is returned.
Pagination
----------
To reduce load on the service, list operations will return a maximum
number of items at a time. To navigate the collection, the parameters
limit, marker and page\_reverse can be set in the URI. For example:
.. code::
?limit=100&marker=1234&page_reverse=False
The *``marker``* parameter is the ID of the last item in the previous
list. The *``limit``* parameter sets the page size. The
*``page_reverse``* parameter sets the page direction. These parameters
are optional. If the client requests a limit beyond the maximum limit
configured by the deployment, the server returns the maximum limit
number of items.
For convenience, list responses contain atom "next" links and "previous"
links. The last page in the list requested with 'page\_reverse=False'
will not contain "next" link, and the last page in the list requested
with 'page\_reverse=True' will not contain "previous" link. The
following examples illustrate two pages with three items. The first page
was retrieved through:
.. code::
GET http://127.0.0.1:9696/v2.0/networks.json?limit=2
Pagination is an optional feature of OpenStack Networking API, and it
might be disabled. If pagination is disabled, the pagination parameters
will be ignored and return all the items.
If a particular plug-in does not support pagination operations, and
pagination is enabled, the Networking API v2.0 will emulate the
pagination behavior so that users can expect the same behavior
regardless of the particular plug-in running in the background.
Unfortunately OpenStack Networking does not expose any mechanism to tell
user if pagination is supported by particular plug-in or enabled.
**Example Network collection, first page: JSON request**
.. code::
GET /v2.0/networks.json?limit=2 HTTP/1.1
Host: 127.0.0.1:9696
Content-Type: application/json
Accept: application/json
**Example Network collection, first page: JSON response**
.. code::
{
"networks": [
{
"admin_state_up": true,
"id": "396f12f8-521e-4b91-8e21-2e003500433a",
"name": "net3",
"provider:network_type": "vlan",
"provider:physical_network": "physnet1",
"provider:segmentation_id": 1002,
"router:external": false,
"shared": false,
"status": "ACTIVE",
"subnets": [],
"tenant_id": "20bd52ff3e1b40039c312395b04683cf"
},
{
"admin_state_up": true,
"id": "71c1e68c-171a-4aa2-aca5-50ea153a3718",
"name": "net2",
"provider:network_type": "vlan",
"provider:physical_network": "physnet1",
"provider:segmentation_id": 1001,
"router:external": false,
"shared": false,
"status": "ACTIVE",
"subnets": [],
"tenant_id": "20bd52ff3e1b40039c312395b04683cf"
}
],
"networks_links": [
{
"href": "http://127.0.0.1:9696/v2.0/networks.json?limit=2&marker=71c1e68c-171a-4aa2-aca5-50ea153a3718",
"rel": "next"
},
{
"href": "http://127.0.0.1:9696/v2.0/networks.json?limit=2&marker=396f12f8-521e-4b91-8e21-2e003500433a&page_reverse=True",
"rel": "previous"
}
]
}
**Example Network collection, first page: XML request**
.. code::
GET /v2.0/networks.xml?limit=2 HTTP/1.1
Host: 127.0.0.1:9696
Content-Type: application/xml
Accept: application/xml
**Example Network collection, first page: XML response**
.. code::
<?xml version="1.0" ?>
<networks xmlns="http://openstack.org/neutron/api/v2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:provider="http://docs.openstack.org/ext/provider/api/v1.0" xmlns:neutron="http://openstack.org/neutron/api/v2.0" xmlns:router="http://docs.openstack.org/ext/neutron/router/api/v1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<network>
<status>ACTIVE</status>
<subnets neutron:type="list"/>
<name>net3</name>
<provider:physical_network>physnet1</provider:physical_network>
<admin_state_up neutron:type="bool">True</admin_state_up>
<tenant_id>20bd52ff3e1b40039c312395b04683cf</tenant_id>
<provider:network_type>vlan</provider:network_type>
<router:external neutron:type="bool">False</router:external>
<shared neutron:type="bool">False</shared>
<id>396f12f8-521e-4b91-8e21-2e003500433a</id>
<provider:segmentation_id neutron:type="long">1002</provider:segmentation_id>
</network>
<network>
<status>ACTIVE</status>
<subnets neutron:type="list"/>
<name>net2</name>
<provider:physical_network>physnet1</provider:physical_network>
<admin_state_up neutron:type="bool">True</admin_state_up>
<tenant_id>20bd52ff3e1b40039c312395b04683cf</tenant_id>
<provider:network_type>vlan</provider:network_type>
<router:external neutron:type="bool">False</router:external>
<shared neutron:type="bool">False</shared>
<id>71c1e68c-171a-4aa2-aca5-50ea153a3718</id>
<provider:segmentation_id neutron:type="long">1001</provider:segmentation_id>
</network>
<atom:link href="http://127.0.0.1:9696/v2.0/networks.xml?limit=2&amp;marker=71c1e68c-171a-4aa2-aca5-50ea153a3718" rel="next"/>
<atom:link href="http://127.0.0.1:9696/v2.0/networks.xml?limit=2&amp;marker=396f12f8-521e-4b91-8e21-2e003500433a&amp;page_reverse=True" rel="previous"/>
</networks>
The last page won't show the "next" links
**Example Network collection, last page: JSON request**
.. code::
GET /v2.0/networks.json?limit=2&marker=71c1e68c-171a-4aa2-aca5-50ea153a3718 HTTP/1.1
Host: 127.0.0.1:9696
Content-Type: application/json
Accept: application/json
**Example Network collection, last page: JSON response**
.. code::
{
"networks": [
{
"admin_state_up": true,
"id": "b3680498-03da-4691-896f-ef9ee1d856a7",
"name": "net1",
"provider:network_type": "vlan",
"provider:physical_network": "physnet1",
"provider:segmentation_id": 1000,
"router:external": false,
"shared": false,
"status": "ACTIVE",
"subnets": [],
"tenant_id": "c05140b3dc7c4555afff9fab6b58edc2"
}
],
"networks_links": [
{
"href": "http://127.0.0.1:9696/v2.0/networks.json?limit=2&marker=b3680498-03da-4691-896f-ef9ee1d856a7&page_reverse=True",
"rel": "previous"
}
]
}
**Example Network collection, last page: XML request**
.. code::
GET /v2.0/networks.xml?limit=2&marker=71c1e68c-171a-4aa2-aca5-50ea153a3718 HTTP/1.1
Host: 127.0.0.1:9696
Content-Type: application/xml
Accept: application/xml
**Example Network collection, last page: XML response**
.. code::
<?xml version="1.0" ?>
<networks xmlns="http://openstack.org/neutron/api/v2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:provider="http://docs.openstack.org/ext/provider/api/v1.0" xmlns:neutron="http://openstack.org/neutron/api/v2.0" xmlns:router="http://docs.openstack.org/ext/neutron/router/api/v1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<network>
<status>ACTIVE</status>
<subnets neutron:type="list"/>
<name>net1</name>
<provider:physical_network>physnet1</provider:physical_network>
<admin_state_up neutron:type="bool">True</admin_state_up>
<tenant_id>c05140b3dc7c4555afff9fab6b58edc2</tenant_id>
<provider:network_type>vlan</provider:network_type>
<router:external neutron:type="bool">False</router:external>
<shared neutron:type="bool">False</shared>
<id>b3680498-03da-4691-896f-ef9ee1d856a7</id>
<provider:segmentation_id neutron:type="long">1000</provider:segmentation_id>
</network>
<atom:link href="http://127.0.0.1:9696/v2.0/networks.xml?limit=2&amp;marker=b3680498-03da-4691-896f-ef9ee1d856a7&amp;page_reverse=True" rel="previous"/>
</networks>
Sorting
-------
You can use the *``sort_key``* and *``sort_dir``* parameters to sort the
results of list operations. Currently sorting does not work with
extended attributes of resource. The *``sort_key``* and *``sort_dir``*
can be repeated, and the number of *``sort_key``* and *``sort_dir``*
provided must be same. The *``sort_dir``* parameter indicates in which
direction to sort. Acceptable values are ``asc`` (ascending) and
``desc`` (descending).
Sorting is optional feature of OpenStack Networking API, and it might be
disabled. If sorting is disabled, the sorting parameters are ignored.
If a particular plug-in does not support sorting operations and sorting
is enabled, the Networking API v2.0 emulates the sorting behavior so
that users can expect the same behavior regardless of the particular
plug-in that runs in the background.
Unfortunately OpenStack Networking does provide a mechanism to tell
users if specific plug-ins support or have enabled sorting.
Extensions
----------
The Networking API v2.0 is extensible.
The purpose of Networking API v2.0 extensions is to:
- Introduce new features in the API without requiring a version change.
- Introduce vendor-specific niche functionality.
- Act as a proving ground for experimental functionalities that might
be included in a future version of the API.
To programmatically determine which extensions are available, issue a
**GET** request on the **v2.0/extensions** URI.
To query extensions individually by unique alias, issue a **GET**
request on the **/v2.0/extensions/*``alias_name``*** URI. Use this
method to easily determine if an extension is available. If the
extension is not available, a 404 Not Found response is returned.
You can extend existing core API resources with new actions or extra
attributes. Also, you can add new resources as extensions. Extensions
usually have tags that prevent conflicts with other extensions that
define attributes or resources with the same names, and with core
resources and attributes. Because an extension might not be supported by
all plug-ins, the availability of an extension varies with deployments
and the specific plug-in in use.
Faults
------
The Networking API v2.0 returns an error response if a failure occurs
while processing a request. OpenStack Networking uses only standard HTTP
error codes. 4\ *``nn``* errors indicate problems in the particular
request being sent from the client.
Error
Description
400
Bad request
Malformed request URI or body
requested admin state invalid
Invalid values entered
Bulk operations disallowed
Validation failed
Method not allowed for request body (such as trying to update attributes
that can be specified at create-time only)
404
Not Found
Non existent URI
Resource not found
409
Conflict
Port configured on network
IP allocated on subnet
Conflicting IP allocation pools for subnet
500
Internal server error
Internal OpenStack Networking error
503
Service unavailable
Failure in Mac address generation
Users submitting requests to the Networking API v2.0 might also receive
the following errors:
- 401 Unauthorized - If invalid credentials are provided.
- 403 Forbidden - If the user cannot access a specific resource or
perform the requested operation.

6
specs/api/ports.rst Normal file
View File

@ -0,0 +1,6 @@
=====
Ports
=====
List, show information for, create, update, and delete ports.

View File

@ -0,0 +1,131 @@
=========================================
Ports binding extended attributes (ports)
=========================================
Use the Networking API v2.0 with the *``binding``* extended attributes
to get information about, create, and update port objects.
The *``binding``*-prefixed extended attributes for ports are:
**Table Ports binding extended attributes**
Attribute
Type
Required
CRUD\ `:sup:`[a]` <#ftn.crud_network>`__
Default value
Validation constraints
Notes
*``binding:vnic_type``*
String
N/A
CRU
normal
(normal, direct, macvtap)
The vnic type to be bound on the neutron port.
In **POST** and **PUT** operations, specify a value of ``normal``
(virtual nic), ``direct`` (pci passthrough), or ``macvtap`` (virtual
interface with a tap-like software interface). These values support
SR-IOV PCI passthrough networking. The ML2 plug-in supports the
*``vnic_type``*.
In **GET** operations, the *``binding:vnic_type``* extended attribute is
visible to only port owners and administrative users.
*``binding:vif_type``*
String
N/A
R
None
N/A
Read-only. The vif type for the specified port.
Visible to only administrative users.
*``binding:vif_details``*
list(dict)
N/A
R
None
N/A
Read-only. A dictionary that enables the application to pass information
about functions that Networking API v2.0 provides. Specify the following
value: ``port_filter : Boolean`` to define
whether Networking API v2.0 provides port filtering features such as
security group and anti-MAC/IP spoofing.
Visible to only administrative users.
*``binding:host_id``*
uuid-str
N/A
CRU
None
N/A
The ID of the host where the port is allocated. In some cases, different
implementations can run on different hosts.
Visible to only administrative users.
*``binding:profile``*
list(dict)
N/A
CRU
None
N/A
A dictionary that enables the application to pass information about
functions that the Networking API provides. To enable or disable port
filtering features such as security group and anti-MAC/IP spoofing,
specify ``port_filter: True`` or ``port_filter: False``.
Visible to only administrative users.
- **`:sup:`[a]` <#crud_network>`__\ C**. Use the attribute in create
operations.
- **R**. This attribute is returned in response to show and list
operations.
- **U**. You can update the value of this attribute.
- **D**. You can delete the value of this attribute.

View File

@ -0,0 +1,47 @@
============================
Provider networks (provider)
============================
The *``provider``* extended attributes for networks enable
administrative users to specify how network objects map to the
underlying networking infrastructure. These extended attributes also
appear when administrative users query networks.
To this aim, it extends the **network** resource by defining a set of
attributes prefixed with provider.
These attributes are added to the **network** resource:
- provider:network\_type - Specifies the nature of the physical network
mapped to this network resource. Examples are ``flat``, ``vlan``, or
``gre``.
- provider:physical\_network - Identifies the physical network on top
of which this network object is being implemented. The OpenStack
Networking API does not expose any facility for retrieving the list
of available physical networks. As an example, in the Open vSwitch
plug-in this is a symbolic name which is then mapped to specific
bridges on each compute host through the Open vSwitch plug-in
configuration file.
- provider:segmentation\_id - Identifies an isolated segment on the
physical network; the nature of the segment depends on the
segmentation model defined by ``network_type``. For instance, if
``network_type`` is ``vlan``, then this is a ``vlan`` identifier;
otherwise, if ``network_type`` is ``gre``, then this will be a
``gre`` key.
The actual semantics of these attributes depend on the technology back
end of the particular plug-in. See the plug-in documentation and the
*OpenStack Cloud Administrator Guide* to understand which values should
be specific for each of these attributes when OpenStack Networking is
deployed with a particular plug-in. The examples shown in this chapter
refer to the Open vSwitch plug-in.
The default policy settings enable only users with administrative rights
to specify these parameters in requests and to see their values in
responses. By default, the provider network extension attributes are
completely hidden from regular tenants. As a rule of thumb, if these
attributes are not visible in a GET /networks/<network-id> operation,
this implies the user submitting the request is not authorized to view
or manipulate provider network attributes.

9
specs/api/quotas.rst Normal file
View File

@ -0,0 +1,9 @@
======
Quotas
======
Use the ``neutron.conf`` configuration file to define and apply default
quota values to all tenants. This extension enables an administrative
user to define quotas values on a per-tenant basis. For example, an
administrative user can permit tenant A to create at most *``n``*
networks and tenant B to create at most *``n``* networks.

View File

@ -0,0 +1,5 @@
===========================================
Security groups and rules (security-groups)
===========================================
List, create, show information for, and delete security groups and security group rules.

6
specs/api/subnets.rst Normal file
View File

@ -0,0 +1,6 @@
=======
Subnets
=======
List, show information for, create, update, and delete subnet resources.

File diff suppressed because it is too large Load Diff