Do not use prelude section for individual release notes
prelude section is prepared for general comments about a release [1]. At now neutron release notes use prelude section randomly. Some rel notes use it and some do not. This commit drop or move prelude section in Pike release notes. In addition, some guideline on writing a release note to the release notes howto page. Change-Id: I53fefcc3eed30700d095c77d9e000319668097e8
This commit is contained in:
Akihiro Motoki
parent
6f1ecf2466
commit
010b133938
@ -1,5 +1,3 @@
|
||||
---
|
||||
prelude: >
|
||||
Openvswitch L2 agent supports ingress bandwidth limit.
|
||||
features:
|
||||
- The openvswitch L2 agent now supports bi-directional bandwidth limiting.
|
||||
|
||||
@ -1,16 +1,14 @@
|
||||
---
|
||||
prelude: >
|
||||
Add ``data_plane_status`` attribute to port resources to represent the
|
||||
status of the underlying data plane. This attribute is to be managed by
|
||||
entities outside of the Networking service, while the ``status`` attribute
|
||||
is managed by the Networking service. Both status attributes are independent
|
||||
from one another.
|
||||
features:
|
||||
- The port resource can have a ``data_plane_status`` attribute.
|
||||
- Add ``data_plane_status`` attribute to port resources to represent the
|
||||
status of the underlying data plane. This attribute is to be managed
|
||||
by entities outside of the Networking service,
|
||||
while the ``status`` attribute is managed by the Networking service.
|
||||
Both status attributes are independent from one another.
|
||||
Third parties can report via Neutron API issues in the underlying data
|
||||
plane affecting connectivity from/to Neutron ports.
|
||||
Attribute can take values ``None`` (default), ``ACTIVE`` or ``DOWN``,
|
||||
and is readable by users and writable by admins and users granted the
|
||||
``data-plane-integrator`` role. Append ``data_plane_status`` to
|
||||
[ml2]/extension_drivers section to load the extension driver.
|
||||
|
||||
``data-plane-integrator`` role.
|
||||
Append ``data_plane_status`` to ``[ml2] extension_drivers`` config
|
||||
option to load the extension driver.
|
||||
|
||||
@ -1,7 +1,4 @@
|
||||
---
|
||||
prelude: >
|
||||
This release adds support for running Neutron API component with a ``mod_wsgi``
|
||||
compatible web server.
|
||||
features:
|
||||
- Neutron API can now be managed by a ``mod_wsgi`` compatible web server (e.g.
|
||||
``apache2`` (``httpd``), ``nginx``, etc.)
|
||||
|
||||
@ -1,6 +1,5 @@
|
||||
---
|
||||
prelude: >
|
||||
Add 'default' behaviour to QoS policies
|
||||
features:
|
||||
- Neutron now supports having a default QoS policy in a project, assigned
|
||||
- Add 'default' behaviour to QoS policies
|
||||
Neutron now supports having a default QoS policy in a project, assigned
|
||||
automatically to all new networks created.
|
||||
|
||||
@ -1,10 +1,7 @@
|
||||
---
|
||||
prelude: >
|
||||
Default quotas for the following resources were increased: networks (from
|
||||
10 to 100), subnets (from 10 to 100), ports (from 50 to 500).
|
||||
upgrade:
|
||||
- |
|
||||
Default quotas were bumped for the following resources: networks (from 10
|
||||
to 100), subnets (from 10 to 100), ports (from 50 to 500). If you want to
|
||||
stick to old values, consider explicitly setting them in the
|
||||
``neutron.conf`` file.
|
||||
Default quotas were bumped for the following resources: networks (from 10
|
||||
to 100), subnets (from 10 to 100), ports (from 50 to 500). If you want to
|
||||
stick to old values, consider explicitly setting them in the
|
||||
``neutron.conf`` file.
|
||||
|
||||
@ -1,9 +1,4 @@
|
||||
---
|
||||
prelude: >
|
||||
The Neutron API now supports conditional updates to resources with the
|
||||
'revision_number' attribute by setting the desired revision number in
|
||||
an HTTP If-Match header. This allows clients to ensure that a resource
|
||||
hasn't been modified since it was retrieved by the client.
|
||||
features:
|
||||
- |
|
||||
The Neutron API now supports conditional updates to resources with the
|
||||
|
||||
@ -1,13 +1,11 @@
|
||||
---
|
||||
prelude: >
|
||||
Add DVR Floating IP (FIP) Namespace creation event
|
||||
on all nodes, based on the gateway configuration.
|
||||
features:
|
||||
- Proactively create Floating IP Namespace on all compute nodes
|
||||
- Proactively create DVR floating IP namespace on all compute nodes
|
||||
when a gateway is configured.
|
||||
issues:
|
||||
- This might consume public IP Address, but by using
|
||||
subnet service-types as explained in the docs below
|
||||
https://docs.openstack.org/networking-guide/config-service-subnets.html
|
||||
- Creating DVR floating IP namespace on all nodes proactively
|
||||
might consume public IP Address, but by using
|
||||
subnet service-types as explained in `the networking guide
|
||||
<https://docs.openstack.org/neutron/latest/admin/config-service-subnets.html>`__
|
||||
consumers can use the private IPs for floating IP agent gateway ports
|
||||
and need not consume any public IP addresses.
|
||||
|
||||
@ -1,5 +1,4 @@
|
||||
---
|
||||
prelude: >
|
||||
Linuxbridge L2 agent supports ingress bandwidth limit.
|
||||
features:
|
||||
- The linuxbridge L2 agent now supports bi-directional bandwidth limiting.
|
||||
- Linuxbridge L2 agent supports ingress bandwidth limit.
|
||||
The linuxbridge L2 agent now supports bi-directional bandwidth limiting.
|
||||
|
||||
@ -1,7 +1,6 @@
|
||||
---
|
||||
prelude: >
|
||||
The ``openvswitch`` mechanism driver now supports hardware offload via SR-IOV.
|
||||
features:
|
||||
- The ``openvswitch`` mechanism driver now allows binding direct (SR-IOV) ports.
|
||||
Using ``openvswitch`` 2.8.0 and 'Linux Kernel' 4.8 allows to control the SR-IOV VF
|
||||
- The ``openvswitch`` mechanism driver now supports hardware offload via
|
||||
SR-IOV. It allows binding direct (SR-IOV) ports. Using ``openvswitch``
|
||||
2.8.0 and 'Linux Kernel' 4.8 allows to control the SR-IOV VF
|
||||
via OpenFlow control plane and gain accelerated 'Open vSwitch'.
|
||||
@ -1,6 +1,6 @@
|
||||
prelude: >
|
||||
Network QoS policies are now supported for network:router_gateway ports.
|
||||
---
|
||||
features:
|
||||
- |
|
||||
Network QoS policies are now supported for network:router_gateway ports.
|
||||
Neutron QoS policies set on an external network now apply to external
|
||||
router ports (DVR or not).
|
||||
|
||||
@ -1,8 +1,7 @@
|
||||
---
|
||||
prelude: >
|
||||
New API to get details of supported rule types.
|
||||
features:
|
||||
- |
|
||||
New API to get details of supported rule types.
|
||||
The QoS service plugin can now expose details about supported QoS rule
|
||||
types in Neutron deployment.
|
||||
New API call is allowed only for users with admin priviliges.
|
||||
The new API call is allowed only for users with admin priviliges.
|
||||
|
||||
@ -1,17 +1,14 @@
|
||||
---
|
||||
prelude: >
|
||||
Enable creation of VXLANs with different multicast
|
||||
addresses allocated by VNI-address mappings.
|
||||
features:
|
||||
- The ability to control vni-multicast address
|
||||
distribution in linuxbridge agent via new config
|
||||
option - multicast_ranges.
|
||||
- Enable creation of VXLANs with different multicast addresses
|
||||
in linuxbridge agent allocated by VNI-address mappings.
|
||||
A new config option ``multicast_ranges`` was introduced.
|
||||
other:
|
||||
- Example configuration of `multicast_ranges` in
|
||||
ml2_conf.ini under the `[vxlan]` config. section
|
||||
multicast_ranges = 224.0.0.10:10:90,225.0.0.15:100:900
|
||||
- Example configuration of ``multicast_ranges`` in
|
||||
ml2_conf.ini under the ``[vxlan]`` config. section
|
||||
``multicast_ranges = 224.0.0.10:10:90,225.0.0.15:100:900``.
|
||||
For VNI between 10 and 90, the multicast address
|
||||
224.0.0.0.10 will be used, and for 100 through 900
|
||||
225.0.0.15 will be used. Other VNI values will get
|
||||
standard `vxlan_group` address. For more info see RFE
|
||||
`<https://bugs.launchpad.net/neutron/+bug/1579068>`
|
||||
standard ``vxlan_group`` address. For more info see RFE
|
||||
https://bugs.launchpad.net/neutron/+bug/1579068
|
||||
|
||||
@ -12,6 +12,14 @@ Writing release notes
|
||||
For information on how to create release notes, please consult the
|
||||
`reno documentation <https://docs.openstack.org/reno/latest/user/usage.html>`__.
|
||||
|
||||
Please keep the following in your mind when you write release notes.
|
||||
|
||||
* **Avoid using "prelude" section** for individual release notes.
|
||||
"prelude" section is for general comments about the release.
|
||||
* **Use one entry per section** (like "feature" or "upgrade").
|
||||
All entries which belong to a same release will be merged and rendered,
|
||||
so there is less meaning to use multiple entries by a single topic.
|
||||
|
||||
Maintaining release notes
|
||||
-------------------------
|
||||
|
||||
|
||||
@ -18,10 +18,13 @@
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
README.rst
|
||||
unreleased
|
||||
ocata
|
||||
newton
|
||||
mitaka
|
||||
liberty
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
README.rst
|
||||
|
||||
Loading…
Reference in New Issue
Block a user