diff --git a/releasenotes/notes/Ingress-bandwidth-limit-in-openvswitch-agent-51cda9bb6b511885.yaml b/releasenotes/notes/Ingress-bandwidth-limit-in-openvswitch-agent-51cda9bb6b511885.yaml index dc2e8487b86..c90c088296d 100644 --- a/releasenotes/notes/Ingress-bandwidth-limit-in-openvswitch-agent-51cda9bb6b511885.yaml +++ b/releasenotes/notes/Ingress-bandwidth-limit-in-openvswitch-agent-51cda9bb6b511885.yaml @@ -1,5 +1,3 @@ --- -prelude: > - Openvswitch L2 agent supports ingress bandwidth limit. features: - The openvswitch L2 agent now supports bi-directional bandwidth limiting. diff --git a/releasenotes/notes/add-port-data-plane-status-12726c964210b374.yaml b/releasenotes/notes/add-port-data-plane-status-12726c964210b374.yaml index f86cce5bf07..42604660bee 100644 --- a/releasenotes/notes/add-port-data-plane-status-12726c964210b374.yaml +++ b/releasenotes/notes/add-port-data-plane-status-12726c964210b374.yaml @@ -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. diff --git a/releasenotes/notes/add-wsgi-script-support-e611fa5b5c2043a5.yaml b/releasenotes/notes/add-wsgi-script-support-e611fa5b5c2043a5.yaml index 27802cac399..3107c2582c0 100644 --- a/releasenotes/notes/add-wsgi-script-support-e611fa5b5c2043a5.yaml +++ b/releasenotes/notes/add-wsgi-script-support-e611fa5b5c2043a5.yaml @@ -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.) diff --git a/releasenotes/notes/add_is_default_to_qos_policies-f7c6bbac08d474d5.yaml b/releasenotes/notes/add_is_default_to_qos_policies-f7c6bbac08d474d5.yaml index afda1e9d62a..937eb3db367 100644 --- a/releasenotes/notes/add_is_default_to_qos_policies-f7c6bbac08d474d5.yaml +++ b/releasenotes/notes/add_is_default_to_qos_policies-f7c6bbac08d474d5.yaml @@ -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. diff --git a/releasenotes/notes/bump-default-quotas-810570badb378c50.yaml b/releasenotes/notes/bump-default-quotas-810570badb378c50.yaml index 036edc4327b..dd30a8b50ea 100644 --- a/releasenotes/notes/bump-default-quotas-810570badb378c50.yaml +++ b/releasenotes/notes/bump-default-quotas-810570badb378c50.yaml @@ -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. diff --git a/releasenotes/notes/conditional_updates-10b9aa66fd144217.yaml b/releasenotes/notes/conditional_updates-10b9aa66fd144217.yaml index 331850ceb16..ee7468832a4 100644 --- a/releasenotes/notes/conditional_updates-10b9aa66fd144217.yaml +++ b/releasenotes/notes/conditional_updates-10b9aa66fd144217.yaml @@ -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 diff --git a/releasenotes/notes/dvr-fip-namespace-on-all-nodes-c4da7ccd60ee62f5.yaml b/releasenotes/notes/dvr-fip-namespace-on-all-nodes-c4da7ccd60ee62f5.yaml index 4025603a0db..4fd8b14963e 100644 --- a/releasenotes/notes/dvr-fip-namespace-on-all-nodes-c4da7ccd60ee62f5.yaml +++ b/releasenotes/notes/dvr-fip-namespace-on-all-nodes-c4da7ccd60ee62f5.yaml @@ -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 + `__ consumers can use the private IPs for floating IP agent gateway ports and need not consume any public IP addresses. diff --git a/releasenotes/notes/ingress-bandwidth-limit-in-linuxbridge-agent-50a2dad610401474.yaml b/releasenotes/notes/ingress-bandwidth-limit-in-linuxbridge-agent-50a2dad610401474.yaml index 69a745ee6b8..3e13d2e5c79 100644 --- a/releasenotes/notes/ingress-bandwidth-limit-in-linuxbridge-agent-50a2dad610401474.yaml +++ b/releasenotes/notes/ingress-bandwidth-limit-in-linuxbridge-agent-50a2dad610401474.yaml @@ -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. diff --git a/releasenotes/notes/ovs_hardware_offload_support-798d3896ab2c4b1d.yaml b/releasenotes/notes/ovs_hardware_offload_support-798d3896ab2c4b1d.yaml index 287afb22f9c..d7bdbc9f53e 100644 --- a/releasenotes/notes/ovs_hardware_offload_support-798d3896ab2c4b1d.yaml +++ b/releasenotes/notes/ovs_hardware_offload_support-798d3896ab2c4b1d.yaml @@ -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'. \ No newline at end of file + - 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'. diff --git a/releasenotes/notes/qos-for-router-gateway-02340f7aa8be3b0d.yaml b/releasenotes/notes/qos-for-router-gateway-02340f7aa8be3b0d.yaml index 1423c100ea9..b3c54cf57a6 100644 --- a/releasenotes/notes/qos-for-router-gateway-02340f7aa8be3b0d.yaml +++ b/releasenotes/notes/qos-for-router-gateway-02340f7aa8be3b0d.yaml @@ -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). diff --git a/releasenotes/notes/qos-rule-type-details-api-call-27d792980235aec4.yaml b/releasenotes/notes/qos-rule-type-details-api-call-27d792980235aec4.yaml index 945e1616a12..dd5b4373f7f 100644 --- a/releasenotes/notes/qos-rule-type-details-api-call-27d792980235aec4.yaml +++ b/releasenotes/notes/qos-rule-type-details-api-call-27d792980235aec4.yaml @@ -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. diff --git a/releasenotes/notes/vxlan-multicast-groups-distribution-linuxbridge-9337019c961c01a7.yaml b/releasenotes/notes/vxlan-multicast-groups-distribution-linuxbridge-9337019c961c01a7.yaml index 91de52f5ac0..374226621cb 100644 --- a/releasenotes/notes/vxlan-multicast-groups-distribution-linuxbridge-9337019c961c01a7.yaml +++ b/releasenotes/notes/vxlan-multicast-groups-distribution-linuxbridge-9337019c961c01a7.yaml @@ -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 - `` + standard ``vxlan_group`` address. For more info see RFE + https://bugs.launchpad.net/neutron/+bug/1579068 diff --git a/releasenotes/source/README.rst b/releasenotes/source/README.rst index a926ea8db71..67605dab59c 100644 --- a/releasenotes/source/README.rst +++ b/releasenotes/source/README.rst @@ -12,6 +12,14 @@ Writing release notes For information on how to create release notes, please consult the `reno documentation `__. +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 ------------------------- diff --git a/releasenotes/source/index.rst b/releasenotes/source/index.rst index 70ab663b0a3..f7dea210a05 100644 --- a/releasenotes/source/index.rst +++ b/releasenotes/source/index.rst @@ -18,10 +18,13 @@ .. toctree:: :maxdepth: 1 - README.rst unreleased ocata newton mitaka liberty +.. toctree:: + :maxdepth: 1 + + README.rst