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
changes/72/490772/1
Akihiro Motoki 5 years ago
parent 6f1ecf2466
commit 010b133938
  1. 2
      releasenotes/notes/Ingress-bandwidth-limit-in-openvswitch-agent-51cda9bb6b511885.yaml
  2. 18
      releasenotes/notes/add-port-data-plane-status-12726c964210b374.yaml
  3. 3
      releasenotes/notes/add-wsgi-script-support-e611fa5b5c2043a5.yaml
  4. 5
      releasenotes/notes/add_is_default_to_qos_policies-f7c6bbac08d474d5.yaml
  5. 11
      releasenotes/notes/bump-default-quotas-810570badb378c50.yaml
  6. 5
      releasenotes/notes/conditional_updates-10b9aa66fd144217.yaml
  7. 12
      releasenotes/notes/dvr-fip-namespace-on-all-nodes-c4da7ccd60ee62f5.yaml
  8. 5
      releasenotes/notes/ingress-bandwidth-limit-in-linuxbridge-agent-50a2dad610401474.yaml
  9. 9
      releasenotes/notes/ovs_hardware_offload_support-798d3896ab2c4b1d.yaml
  10. 4
      releasenotes/notes/qos-for-router-gateway-02340f7aa8be3b0d.yaml
  11. 5
      releasenotes/notes/qos-rule-type-details-api-call-27d792980235aec4.yaml
  12. 19
      releasenotes/notes/vxlan-multicast-groups-distribution-linuxbridge-9337019c961c01a7.yaml
  13. 8
      releasenotes/source/README.rst
  14. 5
      releasenotes/source/index.rst

@ -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…
Cancel
Save