Merge "Do not use prelude section for individual release notes"
This commit is contained in:
commit
d224effd26
|
@ -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
|
||||
via OpenFlow control plane and gain accelerated 'Open vSwitch'.
|
||||
- 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