Fix style issues in existing-neutron-network spec

1. Heading levels are fixed
2. Wherever lines had scope to include more words and ensuring length
is < 79

Change-Id: I5a78f88fff43b7fb1a7ce04b81172f4105b983e1
This commit is contained in:
vikaschoudhary16 2016-06-14 15:01:34 +05:30
parent 5e09448e60
commit 73c7cde610
1 changed files with 46 additions and 49 deletions

View File

@ -10,21 +10,21 @@ Reuse of the existing Neutron networks
https://blueprints.launchpad.net/kuryr/+spec/existing-neutron-network https://blueprints.launchpad.net/kuryr/+spec/existing-neutron-network
The current Kuryr implementation assumes the Neutron networks, The current Kuryr implementation assumes the Neutron networks, subnetpools,
subnetpools, subnets and ports are created by Kuryr and their subnets and ports are created by Kuryr and their lifecycles are completely
lifecycles are completely controlled by Kuryr. However, in the case controlled by Kuryr. However, in the case where users need to mix the VM
where users need to mix the VM instances and/or the bare metal nodes instances and/or the bare metal nodes with containers, the capability of
with containers, the capability of reusing existing Neutron reusing existing Neutron networks for implementing Kuryr networks becomes
networks for implementing Kuryr networks becomes valuable. valuable.
Problem Description Problem Description
=================== -------------------
The main use case being addressed in this spec is described below: The main use case being addressed in this spec is described below:
* Use of existing Neutron network and subnet resources created * Use of existing Neutron network and subnet resources created independent of
independent of Kuryr Kuryr
With the addition of Tags to neutron resources With the addition of Tags to neutron resources
`Add tags to neutron resources spec`_ `Add tags to neutron resources spec`_
@ -36,21 +36,20 @@ tags for each network to store the corresponding Docker ID.
Proposed Change Proposed Change
=============== ---------------
This specification proposes to use the ``Options`` that can be This specification proposes to use the ``Options`` that can be specified by
specified by user during the creation of Docker networks. We propose user during the creation of Docker networks. We propose to use either the
to use either the Neutron network uuid or name to identify the Neutron Neutron network uuid or name to identify the Neutron network to use. If the
network to use. If the Neutron network uuid or name is specified but Neutron network uuid or name is specified but such a network does not exist or
such a network does not exist or multiple such networks exist in cases multiple such networks exist in cases where a network name is specified, the
where a network name is specified, the create operation fails. create operation fails. Otherwise, the existing network will be used.
Otherwise, the existing network will be used. Similarly, if a subnet Similarly, if a subnet is not associated with the existing network it will be
is not associated with the existing network it will be created by created by Kuryr. Otherwise, the existing subnet will be used.
Kuryr. Otherwise, the existing subnet will be used.
The specified Neutron network is tagged with a well known string such The specified Neutron network is tagged with a well known string such that it
that it can be verified whether it already existed at the time of the can be verified whether it already existed at the time of the creation of the
creation of the Docker network or not. Docker network or not.
.. NOTE(banix): If a Neutron network is specified but it is already .. NOTE(banix): If a Neutron network is specified but it is already
@ -62,7 +61,7 @@ creation of the Docker network or not.
.. _workflow: .. _workflow:
Proposed Workflow Proposed Workflow
----------------- ~~~~~~~~~~~~~~~~~
1. A user creates a Docker network and binds it to an existing Neutron network 1. A user creates a Docker network and binds it to an existing Neutron network
by specifying it's uuid: by specifying it's uuid:
@ -83,24 +82,23 @@ Proposed Workflow
This creates a Docker network with the given name, ``foo`` in this case, by This creates a Docker network with the given name, ``foo`` in this case, by
using the Neutron network with the specified uuid or name. using the Neutron network with the specified uuid or name.
If subnet information is specified by ``--subnet``, ``--gateway`` If subnet information is specified by ``--subnet``, ``--gateway``, and
and ``--ip-range`` as shown in the command above, the corresponding ``--ip-range`` as shown in the command above, the corresponding subnetpools
subnetpools and subnets are created or the exising resources are and subnets are created or the exising resources are appropriately reused
appropriately reused based on the provided information such as based on the provided information such as CIDR. For instance, if the network
CIDR. For instance, if the network with the given UUID in the with the given UUID in the command exists and that network has the subnet
command exists and that network has the subnet whose CIDR is the whose CIDR is the same as what is given by ``--subnet`` and possibly
same as what is given by ``--subnet`` and possibly ``--ip-range``, ``--ip-range``, Kuryr doesn't create a subnet and just leaves the existing
Kuryr doesn't create a subnet and just leaves the existing subnets subnets as they are. Kuryr composes the response from the information of
as they are. Kuryr composes the response from the information of
the created or reused subnet. the created or reused subnet.
It is expected that when Kuryr driver is used, the Kuryr IPAM It is expected that when Kuryr driver is used, the Kuryr IPAM driver is also
driver is also used. used.
If the gateway IP address of the reused Neutron subnet doesn't If the gateway IP address of the reused Neutron subnet doesn't match with
match with the one given by ``--gateway``, Kuryr returns the IP the one given by ``--gateway``, Kuryr returns the IP address set in the
address set in the Neutron subnet nevertheless and the command is Neutron subnet nevertheless and the command is going to fail because of
going to fail because of Dockers's validation against the response. Dockers's validation against the response.
2. A user inspects the created Docker network 2. A user inspects the created Docker network
:: ::
@ -127,8 +125,8 @@ Proposed Workflow
} }
} }
A user can see the Neutron ``uuid`` given in the command is stored A user can see the Neutron ``uuid`` given in the command is stored in the
in the Docker's storage and can be seen by inspecting the network. Docker's storage and can be seen by inspecting the network.
3. A user launches a container and attaches it to the network 3. A user launches a container and attaches it to the network
:: ::
@ -155,23 +153,22 @@ Proposed Workflow
$ sudo docker network rm foo $ sudo docker network rm foo
When an existing Neutron network is used to create a Docker When an existing Neutron network is used to create a Docker network, it is
network, it is tagged such that during the delete operation the tagged such that during the delete operation the Neutron network does not
Neutron network does not get deleted. Currently, if an existing get deleted. Currently, if an existing Neutron network is used, the subnets
Neutron network is used, the subnets associated with it (whether associated with it (whether pre existing or newly created) are preserved as
pre existing or newly created) are preserved as well. In the well. In the future, we may consider tagging subnets themselves or the
future, we may consider tagging subnets themselves or the networks networks (with subnet information) to decide whether a subnet is to be
(with subnet information) to decide whether a subnet is to be
deleted or not. deleted or not.
Challenges Challenges
========== ----------
None None
References References
========== ----------
* `Add tags to neutron resources spec`_ * `Add tags to neutron resources spec`_