openstack
/
manila-specs
Code Issues Proposed changes

Improvements to spec "Extend the design of share networks to span subnets" 

This commit adds some minor improvements to the already approved spec:

* Update statement about User messages
* Update assignees
* Update error cases when creating a share network
* Fix typo and improved wording

Change-Id: Id5250abfa2568b88c7db474d60a6504d3b3411d5
Partially-implements: bp share-network-multiple-subnets
This commit is contained in:
Rodrigo Barbieri 2018-11-27 16:17:21 -02:00
parent 85c87793e8
commit a9ff3b5ded
1 changed files with 15 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
specs/stein/share-network-multiple-subnets.rst
View File

@ -90,7 +90,7 @@ Use Cases
there is a very plausible chance that they mean for their mirrors (share
replicas) or migration targets (share instances) to be on different subnets.
At the same time, there is a possibility that deployers would chose to
At the same time, there is a possibility that deployers would choose to
make giant subnets that span all the availability zones.
- Share servers in manila consume network allocations from a subnet. For
@ -204,7 +204,7 @@ object and the specific subnet is chosen in association with the AZ provided.
``share_network_id`` as an optional parameter. This parameter will be
removed to support this workflow. Since there are no share drivers that
work in ``DHSS = True`` mode and support share replication, we can
remove this unused parameter. See associated launchpad bug [6].
remove this unused parameter. See associated launchpad bug [5].
**Assigning a security service**
@ -250,8 +250,8 @@ document) and foreign keys, ``availability_zone_id`` and
exactly one share network and one availability zone.
The ``manila.db.sqlalchemy.models.ShareServer`` model will stop having a
foreign key binding to ``share_network_id`` and switch to having a foreign
key reference to ``share_network_subnet_id`` instead.
foreign key binding to ``share_network_id`` and switch to having a
foreign key reference to ``share_network_subnet_id`` instead.
No key changes are going to be made to
``manila.db.sqlalchemy.models.ShareNetworkSecurityServiceAssociation``,
@ -293,6 +293,8 @@ Request::
}
Subnet details ``neutron_net_id`` and ``neutron_subnet_id`` are optional.
Although, whenever one of them is specified, both must to be specified,
otherwise the API will respond with ``400 Bad Request``.
``availability_zone`` is optional if one of the following conditions are
met:
@ -577,9 +579,9 @@ They can also define a subnet that can span all availability zones.
Notifications impact
--------------------
None until [5] merges and is fully supported in manila. The work to add
user messages will be proposed with a new blueprint and not part of this work.
We will asynchronously validate the network information during share creation,
and if there is a mismatch with what is specified in the configured network
plugin, we will raise an error user message.
Other end user impact
---------------------
@ -602,12 +604,6 @@ expected to cause a performance impact, but will keep our existing share
network validation isolated from the API allowing for further enhancements
instead of gating changes at the API layer.
There is no end user notification today when the creation of a share fails
because network information in the share network is not valid. The share is
set to ``error`` state and the failure is logged in the share manager logs.
If and when the asynchronous user messages feature [5] is
available in manila, we can enhance the share network validation.
In other words, to minimize the performance impact, no further validation of
network information at the API is recommended by the design introduced in
this spec.
@ -621,8 +617,9 @@ Other deployer impact
availability_zone_hints. Deployers must ensure that neutron services are
running in the desired availability_zones to allow for the network creation
to succeed.
* All existing share networks will be assigned the default availability zone
during the database upgrade to this version of the database changes.
* All existing share networks will have their subnet (if existing) designated
as ``default`` after the database upgrade to this version of the
database changes.
Developer impact
----------------
@ -643,11 +640,8 @@ Assignee(s)
-----------
Primary assignee:
| gouthamr
| ganso
Other contributors:
| yogesh
| bswartz
Work Items
----------
@ -661,17 +655,11 @@ Work Items
Dependencies
============
``nova-network`` has officially been deprecated [7] in the Newton release.
We have proposed [8] to stop supporting it in Newton. This spec hides the
fact that ``nova-network`` is currently a supported way of creating a share
network. Regardless of how we decide to remove ``nova-network``, this work
can progress in parallel.
The evolution of share replication to cover the ``DHSS = True`` use case is
dependant on this change. Once this work is completed, share drivers that
support ``DHSS = True`` mode can support share replication. As a
pre-requisite correction, the Share replica API should no longer support
specifying the ``share_network_id``. [6]
specifying the ``share_network_id``. [5]
Testing
=======
@ -711,10 +699,4 @@ References
[4]: http://docs.openstack.org/mitaka/networking-guide/adv-config-availability-zone.html
[5]: https://blueprints.launchpad.net/manila/+spec/user-messages
[6]: https://bugs.launchpad.net/manila/+bug/1588144
[7]: https://review.openstack.org/#/c/310539/
[8]: http://lists.openstack.org/pipermail/openstack-dev/2016-June/096517.html
[5]: https://bugs.launchpad.net/manila/+bug/1588144