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

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.

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
+    ``data-plane-integrator`` role.
-    [ml2]/extension_drivers section to load the extension driver.
+    Append ``data_plane_status`` to ``[ml2] extension_drivers`` config
-
+    option to load the extension driver.

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.)

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.

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
+    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
+    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
+    stick to old values, consider explicitly setting them in the
-      ``neutron.conf`` file.
+    ``neutron.conf`` file.

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

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
+  - Creating DVR floating IP namespace on all nodes proactively
-    subnet service-types as explained in the docs below
+    might consume public IP Address, but by using
-    https://docs.openstack.org/networking-guide/config-service-subnets.html
+    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.

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.

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.
+  - The ``openvswitch`` mechanism driver now supports hardware offload via
-    Using ``openvswitch`` 2.8.0 and 'Linux Kernel' 4.8 allows to control the SR-IOV VF
+    SR-IOV. It allows binding direct (SR-IOV) ports. Using ``openvswitch``
-    via OpenFlow control plane and gain accelerated 'Open vSwitch'.
+    2.8.0 and 'Linux Kernel' 4.8 allows to control the SR-IOV VF
+    via OpenFlow control plane and gain accelerated 'Open vSwitch'.

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).

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.

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
+  - Enable creation of VXLANs with different multicast addresses
-    distribution in linuxbridge agent via new config
+    in linuxbridge agent allocated by VNI-address mappings.
-    option - multicast_ranges.
+    A new config option ``multicast_ranges`` was introduced.
 other:
-  - Example configuration of `multicast_ranges` in
+  - Example configuration of ``multicast_ranges`` in
-    ml2_conf.ini under the `[vxlan]` config. section
+    ml2_conf.ini under the ``[vxlan]`` config. section
-    multicast_ranges = 224.0.0.10:10:90,225.0.0.15:100:900
+    ``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>`
+    https://bugs.launchpad.net/neutron/+bug/1579068

releasenotes/source/README.rst

@@ -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
 -------------------------
 

releasenotes/source/index.rst

@@ -18,10 +18,13 @@
 .. toctree::
    :maxdepth: 1
 
-   README.rst
    unreleased
    ocata
    newton
    mitaka
    liberty
 
+.. toctree::
+   :maxdepth: 1
+
+   README.rst