diff --git a/releasenotes/notes/Adds-http_proxy_to_wsgi-middleware-24e8271cbd94ffdf.yaml b/releasenotes/notes/Adds-http_proxy_to_wsgi-middleware-24e8271cbd94ffdf.yaml index 8decbb0ce1e..06e7dd22f18 100644 --- a/releasenotes/notes/Adds-http_proxy_to_wsgi-middleware-24e8271cbd94ffdf.yaml +++ b/releasenotes/notes/Adds-http_proxy_to_wsgi-middleware-24e8271cbd94ffdf.yaml @@ -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. diff --git a/releasenotes/notes/Dscp-marking-for-linuxbridge-agent-e765d0d934fa4017.yaml b/releasenotes/notes/Dscp-marking-for-linuxbridge-agent-e765d0d934fa4017.yaml index 40126132d76..4027a4c37bc 100644 --- a/releasenotes/notes/Dscp-marking-for-linuxbridge-agent-e765d0d934fa4017.yaml +++ b/releasenotes/notes/Dscp-marking-for-linuxbridge-agent-e765d0d934fa4017.yaml @@ -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. diff --git a/releasenotes/notes/add-keepalived-vrrp-healt-check-f23ed7c853151484.yaml b/releasenotes/notes/add-keepalived-vrrp-healt-check-f23ed7c853151484.yaml index a3eb638ddf3..b3efcd65a07 100644 --- a/releasenotes/notes/add-keepalived-vrrp-healt-check-f23ed7c853151484.yaml +++ b/releasenotes/notes/add-keepalived-vrrp-healt-check-f23ed7c853151484.yaml @@ -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". diff --git a/releasenotes/notes/add-minimum-bandwidth-support-linuxbridge-9dc9d4458d8affef.yaml b/releasenotes/notes/add-minimum-bandwidth-support-linuxbridge-9dc9d4458d8affef.yaml index 05da4fcfa7e..c08b25c23dd 100644 --- a/releasenotes/notes/add-minimum-bandwidth-support-linuxbridge-9dc9d4458d8affef.yaml +++ b/releasenotes/notes/add-minimum-bandwidth-support-linuxbridge-9dc9d4458d8affef.yaml @@ -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. diff --git a/releasenotes/notes/add-placement-api-configuration-options-f1611d0909bf6166.yaml b/releasenotes/notes/add-placement-api-configuration-options-f1611d0909bf6166.yaml index 83d19432dff..ba141541d58 100644 --- a/releasenotes/notes/add-placement-api-configuration-options-f1611d0909bf6166.yaml +++ b/releasenotes/notes/add-placement-api-configuration-options-f1611d0909bf6166.yaml @@ -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``. diff --git a/releasenotes/notes/deprecate-SRIOV-physical_device_mappings-67dd3317181eb513.yaml b/releasenotes/notes/deprecate-SRIOV-physical_device_mappings-67dd3317181eb513.yaml index 7d4ad6f1c0a..4d5dad7ac32 100644 --- a/releasenotes/notes/deprecate-SRIOV-physical_device_mappings-67dd3317181eb513.yaml +++ b/releasenotes/notes/deprecate-SRIOV-physical_device_mappings-67dd3317181eb513.yaml @@ -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``. diff --git a/releasenotes/notes/deprecate-send_arp_for_ha-0281853632f58e8d.yaml b/releasenotes/notes/deprecate-send_arp_for_ha-0281853632f58e8d.yaml index 28b700d0966..7c41c9eb6d6 100644 --- a/releasenotes/notes/deprecate-send_arp_for_ha-0281853632f58e8d.yaml +++ b/releasenotes/notes/deprecate-send_arp_for_ha-0281853632f58e8d.yaml @@ -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. diff --git a/releasenotes/notes/designate-driver-keystonev3-8e70d152e84388e0.yaml b/releasenotes/notes/designate-driver-keystonev3-8e70d152e84388e0.yaml index a7c904ea491..daa9f1596ba 100644 --- a/releasenotes/notes/designate-driver-keystonev3-8e70d152e84388e0.yaml +++ b/releasenotes/notes/designate-driver-keystonev3-8e70d152e84388e0.yaml @@ -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``)." diff --git a/releasenotes/notes/dhcp-domain-removed-cc5bc6e2129fdf7f.yaml b/releasenotes/notes/dhcp-domain-removed-cc5bc6e2129fdf7f.yaml index 7faaccd0b53..57e408d24e2 100644 --- a/releasenotes/notes/dhcp-domain-removed-cc5bc6e2129fdf7f.yaml +++ b/releasenotes/notes/dhcp-domain-removed-cc5bc6e2129fdf7f.yaml @@ -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. diff --git a/releasenotes/notes/dhcp-for-service-subnets-06f03d902f2fb738.yaml b/releasenotes/notes/dhcp-for-service-subnets-06f03d902f2fb738.yaml deleted file mode 100644 index 704d549ace0..00000000000 --- a/releasenotes/notes/dhcp-for-service-subnets-06f03d902f2fb738.yaml +++ /dev/null @@ -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 `_ for - more details. diff --git a/releasenotes/notes/dhcp-ipv6-address-update-ff18d1eb0c196bce.yaml b/releasenotes/notes/dhcp-ipv6-address-update-ff18d1eb0c196bce.yaml index 7070c9b6b2e..6b65dd912a3 100644 --- a/releasenotes/notes/dhcp-ipv6-address-update-ff18d1eb0c196bce.yaml +++ b/releasenotes/notes/dhcp-ipv6-address-update-ff18d1eb0c196bce.yaml @@ -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 `_. + - 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 `_. 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. diff --git a/releasenotes/notes/fip-janitor-53f0d42a7471c5ed.yaml b/releasenotes/notes/fip-janitor-53f0d42a7471c5ed.yaml index 54ed6c635e0..04e4e111db6 100644 --- a/releasenotes/notes/fip-janitor-53f0d42a7471c5ed.yaml +++ b/releasenotes/notes/fip-janitor-53f0d42a7471c5ed.yaml @@ -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. diff --git a/releasenotes/notes/iptables-fail-on-missing-sysctl-bridge-firewalling-912f157b5671363f.yaml b/releasenotes/notes/iptables-fail-on-missing-sysctl-bridge-firewalling-912f157b5671363f.yaml index d898e15b922..059766d951f 100644 --- a/releasenotes/notes/iptables-fail-on-missing-sysctl-bridge-firewalling-912f157b5671363f.yaml +++ b/releasenotes/notes/iptables-fail-on-missing-sysctl-bridge-firewalling-912f157b5671363f.yaml @@ -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. diff --git a/releasenotes/notes/netns_cleanup_kill_procs-af88d8c47c07dd9c.yaml b/releasenotes/notes/netns_cleanup_kill_procs-af88d8c47c07dd9c.yaml index b231a698632..105b1a78d3e 100644 --- a/releasenotes/notes/netns_cleanup_kill_procs-af88d8c47c07dd9c.yaml +++ b/releasenotes/notes/netns_cleanup_kill_procs-af88d8c47c07dd9c.yaml @@ -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. diff --git a/releasenotes/notes/oslo.messaging.notify.drivers-abb0d17b9e1bd470.yaml b/releasenotes/notes/oslo.messaging.notify.drivers-abb0d17b9e1bd470.yaml index fdf1f7ba528..e3b327d8b7e 100644 --- a/releasenotes/notes/oslo.messaging.notify.drivers-abb0d17b9e1bd470.yaml +++ b/releasenotes/notes/oslo.messaging.notify.drivers-abb0d17b9e1bd470.yaml @@ -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. diff --git a/releasenotes/notes/remove-min-l3-agents-per-router-27aef7d91dec0348.yaml b/releasenotes/notes/remove-min-l3-agents-per-router-27aef7d91dec0348.yaml index ddc8bb8567c..66a6ae74106 100644 --- a/releasenotes/notes/remove-min-l3-agents-per-router-27aef7d91dec0348.yaml +++ b/releasenotes/notes/remove-min-l3-agents-per-router-27aef7d91dec0348.yaml @@ -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. diff --git a/releasenotes/notes/sending-garp-for-l3-ha-c118871833ad8743.yaml b/releasenotes/notes/sending-garp-for-l3-ha-c118871833ad8743.yaml index afcd67053b2..8a7dfd3ef05 100644 --- a/releasenotes/notes/sending-garp-for-l3-ha-c118871833ad8743.yaml +++ b/releasenotes/notes/sending-garp-for-l3-ha-c118871833ad8743.yaml @@ -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``. diff --git a/releasenotes/notes/timestamp_format_change-73eda78566b4690b.yaml b/releasenotes/notes/timestamp_format_change-73eda78566b4690b.yaml index a93db4c4ba8..8a8ea303d37 100644 --- a/releasenotes/notes/timestamp_format_change-73eda78566b4690b.yaml +++ b/releasenotes/notes/timestamp_format_change-73eda78566b4690b.yaml @@ -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. diff --git a/releasenotes/notes/use-pyroute2-in-ip-lib-558bfea8f14d1fea.yaml b/releasenotes/notes/use-pyroute2-in-ip-lib-558bfea8f14d1fea.yaml index 3b95a677aec..38076c88cc9 100644 --- a/releasenotes/notes/use-pyroute2-in-ip-lib-558bfea8f14d1fea.yaml +++ b/releasenotes/notes/use-pyroute2-in-ip-lib-558bfea8f14d1fea.yaml @@ -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``. diff --git a/releasenotes/notes/vhost-user-reconnect-7650134520022e7d.yaml b/releasenotes/notes/vhost-user-reconnect-7650134520022e7d.yaml index cffc194ed45..2ee0cc77e47 100644 --- a/releasenotes/notes/vhost-user-reconnect-7650134520022e7d.yaml +++ b/releasenotes/notes/vhost-user-reconnect-7650134520022e7d.yaml @@ -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.