Merge "Multiple tweaks for Ocata release notes"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
cdeb93b0b3
@ -1,11 +1,11 @@
|
||||
---
|
||||
features:
|
||||
- Middleware was added to parse the X-Forwarded-Proto HTTP header or the
|
||||
Proxy protocol in order to help neutron respond with the correct URL refs
|
||||
when it's put behind a TLS proxy (such as HAProxy). This adds
|
||||
http_proxy_to_wsgi middleware to the pipeline. This middleware is disabled
|
||||
by default, but can be enabled via a configuration option in the
|
||||
oslo_middleware group.
|
||||
- Middleware was added to parse the ``X-Forwarded-Proto`` HTTP header or the
|
||||
Proxy protocol in order to help Neutron respond with the correct URL
|
||||
references when it's put behind a TLS proxy such as ``haproxy``. This adds
|
||||
``http_proxy_to_wsgi`` middleware to the pipeline. This middleware is
|
||||
disabled by default, but can be enabled via a configuration option in the
|
||||
``[oslo_middleware]`` group.
|
||||
upgrade:
|
||||
- The api-paste.ini configuration file for the paste pipeline was updated to
|
||||
add the http_proxy_to_wsgi middleware.
|
||||
- The ``api-paste.ini`` configuration file for the paste pipeline was updated
|
||||
to add the ``http_proxy_to_wsgi`` middleware.
|
||||
|
||||
@ -1,6 +1,3 @@
|
||||
---
|
||||
prelude: >
|
||||
The LinuxBridge agent now supports QoS DSCP marking.
|
||||
features:
|
||||
- The LinuxBridge agent can now configure DSCP marking for packets outgoing
|
||||
for ports with QoS policy.
|
||||
- The Linux Bridge agent now supports QoS DSCP marking rules.
|
||||
|
||||
@ -1,11 +1,9 @@
|
||||
---
|
||||
prelude: >
|
||||
Keepalived VRRP health check functionality to enable verification of
|
||||
connectivity from the "master" router to all gateways.
|
||||
features:
|
||||
- Activation of this feature enables gateway connectivity validation and
|
||||
rescheduling of the "master" router to another node when connectivity
|
||||
is lost. If all routers lose connectivity to the gateways, the election
|
||||
process will be repeated round-robin until one of the routers restores
|
||||
its gateway connection. In the mean time, all of the routers will be
|
||||
reported as "master".
|
||||
- Keepalived VRRP health check functionality to enable verification of
|
||||
connectivity from the "master" router to all gateways. Activation of this
|
||||
feature enables gateway connectivity validation and rescheduling of the
|
||||
"master" router to another node when connectivity is lost. If all routers
|
||||
lose connectivity to the gateways, the election process will be repeated
|
||||
round-robin until one of the routers restores its gateway connection. In
|
||||
the mean time, all of the routers will be reported as "master".
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
features:
|
||||
- Linux Bridge now supports egress minimum bandwidth configuration.
|
||||
- Linux Bridge driver now supports QoS egress minimum bandwidth limit rules.
|
||||
deprecations:
|
||||
- Configuration parameters ``kernel_hz`` and ``tbf_latency`` in ``QoS``
|
||||
section have been removed, because tc-tbf is no longer used.
|
||||
- Configuration options ``kernel_hz`` and ``tbf_latency`` in ``[qos]``
|
||||
section have been removed due to being no longer used.
|
||||
|
||||
@ -1,14 +1,11 @@
|
||||
---
|
||||
prelude: >
|
||||
Add configuration options to enable the segments plugin to use the
|
||||
placement ReST API. This API enables the segments plugin to influence
|
||||
the placement of instances based on the availability of IPv4 addresses
|
||||
in routed networks.
|
||||
features:
|
||||
- A new section is added to neutron.conf, `[placement]`.
|
||||
- The `[placement]` section has two new options.
|
||||
- First option, `region_name`, indicates the placement region to use. This
|
||||
option is useful if keystone manages more than one region.
|
||||
- Second option, `endpoint_type`, indicates the type of the placement
|
||||
endpoint to use. This endpoint will be looked up in the keystone catalog
|
||||
and should be one of 'public', 'internal' or 'admin'.
|
||||
- Add a new configuration section, ``[placement]``, with two new options that
|
||||
allow to make ``segments`` plugin to use the ``Compute`` placement ReST
|
||||
API. This API allows to influence node placement of instances based on
|
||||
availability of IPv4 addresses in routed networks. The first option,
|
||||
`region_name`, indicates the placement region to use. This option is useful
|
||||
if keystone manages more than one region. The second option,
|
||||
`endpoint_type`, determines the type of a placement endpoint to use. This
|
||||
endpoint will be looked up in the keystone catalog and should be one of
|
||||
``public``, ``internal`` or ``admin``.
|
||||
|
||||
@ -1,7 +1,6 @@
|
||||
---
|
||||
deprecations:
|
||||
- The 'physical_device_mappings' option is deprecated
|
||||
and will be removed in Pike. The PCI device validation
|
||||
is made in Nova with the 'pci_whitelist' config option.
|
||||
Therefore it is redundant to validate it in Neutron
|
||||
with physical_device_mappings.
|
||||
- The ``physical_device_mappings`` option is deprecated and will be removed
|
||||
in Pike. PCI device validation is done in Nova, controlled via the
|
||||
``pci_whitelist`` configuration option. Therefore it is redundant to
|
||||
validate it in Neutron with ``physical_device_mappings``.
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
---
|
||||
deprecations:
|
||||
- L3 agent send_arp_for_ha configuration option is deprecated and will be
|
||||
removed in Pike. The functionality will remain and the agent will send
|
||||
three gratuitious ARPs whenever a new floating IP is configured.
|
||||
- The L3 agent ``send_arp_for_ha configuration`` option is deprecated and
|
||||
will be removed in Pike. The functionality will remain, and the agent will
|
||||
send three gratuitious ARPs whenever a new floating IP is configured.
|
||||
|
||||
@ -1,9 +1,7 @@
|
||||
---
|
||||
prelude: >
|
||||
Designate driver can use Keystone v3 auth options.
|
||||
features:
|
||||
- "[designate] section accepts now auth_type parameter,
|
||||
and the usual keystoneauth options (e.g. auth_url,
|
||||
username, user_domain_name, password, project_name,
|
||||
project_domain_name), so Keystone v3 endpoints can
|
||||
be used."
|
||||
- Designate driver can now use Keystone v3 authentication options. "The
|
||||
``[designate]`` section now accepts the ``auth_type`` option, as well as
|
||||
other ``keystoneauth`` options (e.g. ``auth_url``, ``username``,
|
||||
``user_domain_name``, ``password``, ``project_name``,
|
||||
``project_domain_name``)."
|
||||
|
||||
@ -1,5 +1,4 @@
|
||||
upgrade:
|
||||
- The configuration option dhcp_domain in the
|
||||
dhcp_agent.ini file was deprecated in the Liberty
|
||||
cycle. This value is no longer supported, dns_domain
|
||||
in neutron.conf should be used instead.
|
||||
- The ``dhcp_domain`` DHCP agent configuration option was deprecated in
|
||||
Liberty cycle, and now is no longer used. The ``dns_domain`` option should
|
||||
be used instead.
|
||||
|
||||
@ -1,10 +0,0 @@
|
||||
---
|
||||
fixes:
|
||||
- A special case has been added to allow the creation of DHCP ports
|
||||
on Service Subnets that do not have the service type "network:dhcp",
|
||||
provided that the subnet has 'enable_dhcp' set to 'True'.
|
||||
This fixes the recurring error seen when neutron attempts to
|
||||
automatically create a DHCP port on a dhcp-enabled subnet after the
|
||||
subnet is created. See bug report
|
||||
`1636963 <https://bugs.launchpad.net/neutron/+bug/1636963>`_ for
|
||||
more details.
|
||||
@ -1,19 +1,12 @@
|
||||
---
|
||||
prelude: >
|
||||
IPv6 addresses in DHCP namespaces will now be
|
||||
(correctly) statically configured by the DHCP agent.
|
||||
fixes:
|
||||
- There is a race condition when adding ports in
|
||||
DHCP namespaces where an IPv6 address could be
|
||||
dynamically created via SLAAC from a Router
|
||||
Advertisement sent from the L3 agent, leading to
|
||||
a failure to start the DHCP agent. This bug has
|
||||
been fixed, but care must be taken on an upgrade
|
||||
dealing with any possibly stale dynamic addresses.
|
||||
For more information, see bug
|
||||
`1627902 <https://launchpad.net/bugs/1627902>`_.
|
||||
- There is a race condition when adding ports in DHCP namespaces where an
|
||||
IPv6 address could be dynamically created via SLAAC from a Router
|
||||
Advertisement sent from the L3 agent, leading to a failure to start the
|
||||
DHCP agent. This bug has been fixed, but care must be taken on an upgrade
|
||||
dealing with any potentially stale dynamic addresses. For more
|
||||
information, see bug `1627902 <https://launchpad.net/bugs/1627902>`_.
|
||||
upgrade:
|
||||
- On upgrade, IPv6 addresses in the DHCP namespaces
|
||||
that have been created dynmically via SLAAC will be
|
||||
removed, and a static IPv6 address will be added
|
||||
instead.
|
||||
- On upgrade, IPv6 addresses in DHCP namespaces that have been created
|
||||
dynamically via SLAAC will be removed, and static IPv6 addresses will be
|
||||
added instead.
|
||||
|
||||
@ -1,20 +1,8 @@
|
||||
---
|
||||
prelude: >
|
||||
Due to changes in internal L3 logic, a server
|
||||
crash/backend failure during FIP creation may
|
||||
leave dangling ports attached on external
|
||||
networks. These ports can be identified by a
|
||||
'PENDING' device_id. The neutron server will
|
||||
attempt a cleanup periodically to address the issue.
|
||||
other:
|
||||
- If a floating IP creation gets interrupted by
|
||||
a server crash or backend failure, a port can
|
||||
be left behind on the external network. Neutron
|
||||
will now automatically clean these up after
|
||||
approximately 10 minutes. This time value is not
|
||||
configurable.
|
||||
- Ports in this state will be visible on the external
|
||||
network to admins, and will have a device_id value
|
||||
of 'PENDING'. They can also be removed manually by
|
||||
an admin if waiting for the periodic job to do it is
|
||||
undesired.
|
||||
- Due to changes in internal L3 logic, a server crash/backend failure during
|
||||
FIP creation may leave dangling ports attached on external networks. These
|
||||
ports can be identified by a ``PENDING`` ``device_id`` parameter. While
|
||||
those ports can also be removed by admins, the ``neutron-server`` service
|
||||
will now also trigger periodic (approximately once in 10 minutes) cleanup
|
||||
to address the issue.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
deprecations:
|
||||
- The iptables firewall driver will no longer enable bridge firewalling in
|
||||
next versions of Neutron. If your distribution overrides the default
|
||||
- The ``iptables`` firewall driver will no longer enable bridge firewalling
|
||||
in next versions of Neutron. If your distribution overrides the default
|
||||
value for any of relevant sysctl settings
|
||||
(``net.bridge.bridge-nf-call-arptables``,
|
||||
``net.bridge.bridge-nf-call-ip6tables``, and
|
||||
@ -11,4 +11,4 @@ deprecations:
|
||||
upgrades:
|
||||
- On newer Linux kernels (3.18+) you will need to load the ``br_netfilter``
|
||||
kernel module before starting an Open vSwitch or Linuxbridge agent using
|
||||
iptables based firewall. Otherwise the agent will fail to start.
|
||||
``iptables`` firewall driver. Otherwise the agent will fail to start.
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
---
|
||||
features:
|
||||
- A new mechanism has been added to netns_cleanup to
|
||||
kill processes that are listening on any port/unix
|
||||
socket within the namespace. This will try to kill
|
||||
them gracefully via SIGTERM and, if they don't die,
|
||||
then a SIGKILL will be sent to the remaining
|
||||
processes to ensure a proper cleanup.
|
||||
- A new mechanism has been added to the ``neutron-netns-cleanup`` tool that
|
||||
allows to kill processes listening on any ``Unix`` or network socket within
|
||||
a namespace. The new mechanism will try to kill those processes gracefully
|
||||
using the ``SIGTERM`` signal and, if they refuse to die, then the
|
||||
``SIGKILL`` signal will be sent to each remaining process to ensure a
|
||||
proper cleanup.
|
||||
|
||||
@ -1,9 +1,11 @@
|
||||
---
|
||||
prelude: |
|
||||
``oslo.messaging.notify.drivers`` entry points have been removed
|
||||
other:
|
||||
- |
|
||||
The ``oslo.messaging.notify.drivers`` entry points that were left in
|
||||
tree for backward compatibility with Icehouse have been removed.
|
||||
Configure notifications using the oslo_messaging configuration options
|
||||
in ``neutron.conf``.
|
||||
upgrade:
|
||||
- Obsolete ``oslo.messaging.notify.drivers`` entrypoints that were left
|
||||
in tree for backwards compatibility with pre-Icehouse releases have been
|
||||
removed. Those are ``neutron.openstack.common.notifier.log_notifier``,
|
||||
``neutron.openstack.common.notifier.no_op_notifier``,
|
||||
``neutron.openstack.common.notifier.test_notifier``,
|
||||
``neutron.openstack.common.notifier.rpc_notifier2``,
|
||||
``neutron.openstack.common.notifier.rpc_notifier``.
|
||||
Use values provided by ``oslo.messaging`` library to configure notification
|
||||
drivers.
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
---
|
||||
upgrade:
|
||||
- The neutron.conf:min_l3_agents_per_router option was
|
||||
deprecated in Newton and removed in Ocata. HA routers
|
||||
- The ``min_l3_agents_per_router`` configuration option was
|
||||
deprecated in Newton cycle and removed in Ocata. HA routers
|
||||
no longer require a minimal number of L3 agents to
|
||||
be created, although obviously require at least
|
||||
two L3 agents to provide HA. The rationale for the
|
||||
be created, although obviously they require at least
|
||||
two L3 agents to provide HA guarantees. The rationale for the
|
||||
removal of the option is the case a router was created
|
||||
just when an agent was not operational. The creation
|
||||
of the router will now succeed and when a second agent
|
||||
of the router will now succeed, and when a second agent
|
||||
resumes operation the router will be scheduled to it
|
||||
providing HA.
|
||||
|
||||
@ -1,18 +1,17 @@
|
||||
---
|
||||
issues:
|
||||
- In kernels < 3.19 net.ipv4.ip_nonlocal_bind was not
|
||||
a per-namespace kernel option. L3 HA sets this option
|
||||
to zero to avoid sending gratuitous ARPs for IP addresses
|
||||
that were removed while processing. If this happens then
|
||||
gratuitous ARPs are going to be sent which might populate
|
||||
ARP caches of peer machines with the wrong MAC address.
|
||||
- In kernels < 3.19 ``net.ipv4.ip_nonlocal_bind`` sysctl option was not
|
||||
isolated to network namespace scope. L3 HA sets this option to zero to
|
||||
avoid sending gratuitous ARPs for IP addresses that were removed while
|
||||
processing. If this happens, then gratuitous ARPs will be sent. It may
|
||||
populate ARP cache tables of peer machines with wrong MAC addresses.
|
||||
fixes:
|
||||
- Versions of keepalived < 1.2.20 don't send gratuitous ARPs
|
||||
when keepalived process receives SIGHUP signal. These
|
||||
versions are not packaged in some Linux distributions like
|
||||
RHEL, CentOS or Ubuntu Xenial. Not sending gratuitous ARPs
|
||||
may lead to peer ARP caches containing wrong information
|
||||
about floating IP addresses until the entry is invalidated.
|
||||
Neutron now sends gratuitous ARPs for all new IP addresses
|
||||
that appear on non-HA interfaces in router namespace which
|
||||
simulates behavior of new versions of keepalived.
|
||||
- Versions of ``keepalived`` < 1.2.20 don't send gratuitous ARPs when
|
||||
keepalived process receives a ``SIGHUP`` signal. These versions are not
|
||||
packaged in some Linux distributions like Red Hat Enterprise Linux 7,
|
||||
CentOS 7, or Ubuntu Xenial. Not sending gratuitous ARPs may lead to peer
|
||||
ARP cache tables containing wrong entries about floating IP addresses until
|
||||
those entries are invalidated. To fix that scenario, Neutron now sends
|
||||
gratuitous ARPs for all new IP addresses that appear on non-HA interfaces
|
||||
in router namespaces. This behavior simulates behavior of new versions of
|
||||
``keepalived``.
|
||||
|
||||
@ -1,16 +1,12 @@
|
||||
---
|
||||
prelude: >
|
||||
- The created_at and updated_at fields available on Neutron
|
||||
resources now include a timezone indicator at the end.
|
||||
Because this is a change in format, the old 'timestamp_core'
|
||||
extension has been removed and replaced with a 'timestamp'
|
||||
extension.
|
||||
features:
|
||||
- The ``created_at`` and ``updated_at`` resource fields now include a
|
||||
timezone indicator at the end. Because this is a change in field format,
|
||||
the old ``timestamp_core`` extension has been removed and replaced with a
|
||||
``standard-attr-timestamp`` extension.
|
||||
upgrade:
|
||||
- The 'timestamp_core' extension has been removed and replaced
|
||||
with the 'standard-attr-timestamp' extension. Objects will still
|
||||
have timestamps in the 'created_at' and 'updated_at' fields, but
|
||||
they will have the timestamp appended to the end of them
|
||||
to be consistent with other OpenStack projects.
|
||||
fixes:
|
||||
- Bug 1561200 has been fixed by including the timezone with
|
||||
Neutron 'created_at' and 'updated_at' fields.
|
||||
- The ``timestamp_core`` extension has been removed and replaced with the
|
||||
``standard-attr-timestamp`` extension. Resources will still have timestamps
|
||||
in the ``created_at`` and ``updated_at`` fields, but timestamps will have
|
||||
time zone info appended to the end to be consistent with other OpenStack
|
||||
projects.
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
---
|
||||
features:
|
||||
- Initial support for oslo.privsep has been added. A usage example,
|
||||
including unit tests, exists with ip_lib.get_routing_table.
|
||||
- Initial support for ``oslo.privsep`` has been added. Most external commands
|
||||
are still executed using ``oslo.rootwrap``.
|
||||
|
||||
@ -1,21 +1,14 @@
|
||||
---
|
||||
features:
|
||||
- vhost-user reconnect is a mechanism which allows
|
||||
a vhost-user frontend to reconnect to a vhost-user
|
||||
backend in the event the backend terminates.
|
||||
This enable a VM utilising a vhost-user interface
|
||||
to reconnect automatically to the backend e.g.
|
||||
a vSwitch without requiring the VM to reboot.
|
||||
In this release, support was added to the neutron
|
||||
Open vSwitch agent and ml2 driver for vhost-user
|
||||
reconnect.
|
||||
- vhost-user reconnect is a mechanism which allows a vhost-user frontend to
|
||||
reconnect to a vhost-user backend in the event the backend terminates
|
||||
either as a result of a graceful shutdown or a crash. This allows a VM
|
||||
utilising a vhost-user interface to reconnect automatically to the backend
|
||||
e.g. Open vSwitch without requiring the VM to reboot. In this release,
|
||||
support was added to the neutron Open vSwitch agent and ``ml2`` driver for
|
||||
vhost-user reconnect.
|
||||
other:
|
||||
- vhost-user reconnect allows VMs using vhost-user
|
||||
interfaces to reconnect to the vhost-user backend if
|
||||
the backend terminates either as a result of a graceful
|
||||
shutdown or a crash without requiring the VM to reboot.
|
||||
- vhost-user reconnect requires dpdk 16.07 and qemu 2.7
|
||||
and ovs 2.6 to function. if an older qemu is used,
|
||||
reconnect will not be available but vhost-user will
|
||||
still function.
|
||||
- vhost-user reconnect requires dpdk 16.07 and qemu 2.7 and openvswitch 2.6
|
||||
to function. if an older qemu is used, reconnect will not be available but
|
||||
vhost-user will still function.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user