Deployment fixes for DHCP and metadata support

OVN native L3 and DHCP don't provide metadata support so config drive
must be used when both are enabled. However, if the conventional DHCP
agent is enabled it can be configured to provide metadata support.

This patch set provides the necessary DevStack and Vagrant deployment
fixes to properly configure DHCP and metadata support. In addition,
documentation and release notes have been updated accordingly. And
finally, the q-meta service was removed from devstackgatekuryrrc,
since the gate job is setup for OVN native services.

Co-Authored-By: Matt Kassawara <[email protected]>
Change-Id: I9f6b23247df01c40c127b0e9daecd12f5721ff50
Related-Bug: #1514488

devstack/computenode-local.conf.sample

@@ -29,12 +29,14 @@ disable_all_services
 enable_service n-cpu
 enable_service ovn-controller
 
-# For multi-node deployments, we recommend testing multiple instances of the
-# DHCP and metadata agents. In a small lab environment with one controller
-# node, you can run them on two or more compute nodes to simulate a more
-# realistic environment. However, in a large lab that potentially simulates
-# a production environment, you should determine whether to run them on
-# controller nodes, network nodes, or some number of compute nodes.
+# For multi-node deployments using conventional DHCP and metadata agents,
+# we recommend testing multiple instances of those agents. In a small
+# lab environment with one controller node, you can run them on two or
+# more compute nodes to simulate a more realistic environment. However,
+# in a large lab that potentially simulates a production environment, you
+# should determine whether to run them on controller nodes, network nodes,
+# or a subset of compute nodes. Deploying too many agents can cause
+# scaling issues, particularly with the message bus.
 #enable_service q-dhcp
 #enable_service q-meta
 
@@ -64,10 +66,6 @@ NOVNCPROXY_URL=http://$SERVICE_HOST:6080/vnc_auto.html
 VNCSERVER_LISTEN=$HOST_IP
 VNCSERVER_PROXYCLIENT_ADDRESS=$VNCSERVER_LISTEN
 
-# If you enable the DHCP agent, configure it to provide a route for
-# metadata to instances.
-ENABLE_ISOLATED_METADATA=True
-
 # Skydive
 #enable_plugin skydive https://github.com/redhat-cip/skydive.git
 #enable_service skydive-agent

devstack/devstackgatekuryrrc

@@ -18,7 +18,7 @@
 # http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/networking-ovn.yaml
 #
 
-export OVERRIDE_ENABLED_SERVICES=kuryr,etcd-server,docker-engine,key,n-api,n-cpu,n-cond,n-sch,n-crt,n-cauth,n-obj,g-api,g-reg,c-sch,c-api,c-vol,rabbit,tempest,mysql,dstat,ovn-northd,ovn-controller,q-svc,q-meta
+export OVERRIDE_ENABLED_SERVICES=kuryr,etcd-server,docker-engine,key,n-api,n-cpu,n-cond,n-sch,n-crt,n-cauth,n-obj,g-api,g-reg,c-sch,c-api,c-vol,rabbit,tempest,mysql,dstat,ovn-northd,ovn-controller,q-svc
 
 export PROJECTS="openstack/networking-ovn openstack/kuryr $PROJECTS"
 export DEVSTACK_LOCAL_CONFIG="enable_plugin networking-ovn git://git.openstack.org/openstack/networking-ovn"

devstack/lib/networking-ovn

@@ -197,6 +197,23 @@ function configure_ovn_plugin {
         fi
     fi
 
+    # NOTE(rtheis): OVN native layer-3 and DHCP services currently lack support
+    # for metadata. Thus, enabling both native services also requires enabling
+    # config drive to provide instances with metadata. However, if you choose the
+    # conventional DHCP agent instead of the native DHCP service, you can
+    # configure it to provide instances with metadata.
+    if is_service_enabled q-dhcp ; then
+        # Conventional DHCP agent must provide all metadata when OVN native
+        # layer-3 is enabled. So for consistency, regardless of the layer-3
+        # support, the conventional DHCP agent will be forced to provide
+        # metadata for all networks.
+        iniset $Q_DHCP_CONF_FILE DEFAULT force_metadata True
+    elif [[ "$OVN_NATIVE_DHCP" == "True" && "$OVN_L3_MODE" == "True" ]]; then
+        if is_service_enabled n-cpu ; then
+            iniset $NOVA_CONF DEFAULT force_config_drive True
+        fi
+    fi
+
     if is_service_enabled q-qos ; then
         NEUTRON_CONF=/etc/neutron/neutron.conf
         iniset $NEUTRON_CONF qos notification_drivers ovn-qos

devstack/local.conf.sample

@@ -30,14 +30,6 @@ enable_service ovn-controller
 disable_service n-net
 enable_service q-svc
 
-# OVN currently uses the conventional DHCP and metadata agents. For
-# single-node deployments, enable them on the controller node. For
-# multi-node deployments, consider disabling them on the controller
-# node and enabling them on the compute node(s) to provide a more
-# realistic environment. For more information, see
-# computenode-local.conf.sample.
-enable_service q-meta
-
 # We have to disable the neutron L2 agent. OVN does not use the L2 agent.
 disable_service q-agt
 
@@ -52,37 +44,43 @@ disable_service q-agt
 # DevStack runs.
 #OVN_UUID=
 
-# Whether to enable using OVN's L3 functionality. If this value is disabled,
-# OpenStack will use the q-l3 functionality.  If you set OVN_L3_MODE to False,
-# you must also enable the q-l3 service.
-# By default OVN_L3_MODE is True
+# OVN native layer-3 service is enabled by default. To use the conventional
+# layer-3 agent, set OVN_L3_MODE to False and enable the q-l3 service. You
+# should also consider enabling the conventional metadata service (q-meta).
 #OVN_L3_MODE=False
 #enable_service q-l3
 disable_service q-l3
 
-# If OVN_L3_Mode is True, the type of OVN L3 Scheduler to use. The OVN L3
-# Scheduler determines the hypervisor/chassis where a routers gateway should
-# be hosted in OVN. The default OVN L3 scheduler is leastloaded
+# If using the OVN native layer-3 service, choose a router scheduler to
+# manage the distribution of router gateways on hypervisors/chassis.
+# Default value is leastloaded.
 #OVN_L3_SCHEDULER=leastloaded
 
-# Whether to enable using OVN's native dhcp support. If this value is disabled,
-# OpenStack will use the q-dhcp functionality.  If you set
-# OVN_NATIVE_DHCP to False you must also enable the q-dhcp service.
-# By default OVN_NATIVE_DHCP is True
+# OVN native DHCP functionality is enabled by default. To use the conventional
+# DHCP agent, set OVN_NATIVE_DHCP to False and enable the q-dhcp service.
+# However, if you choose the conventional DHCP agent instead of the native
+# DHCP service, see the deployment considerations. You should also consider
+# enabling the conventional metadata service (q-meta).
 #OVN_NATIVE_DHCP=False
 #enable_service q-dhcp
 disable_service q-dhcp
 
+# OVN currently relies on the conventional metadata agent to provide instances
+# with metadata. However, this mechanism only works in conjunction with the
+# conventional layer-3 and/or DHCP agents. For single-node deployments, enable
+# the metadata agent on the controller node. For multi-node deployments,
+# the controller node. For multi-node deployments, consider disabling the
+# agent on the controller node and enabling the agent on a subset of compute
+# nodes. For more information, see computenode-local.conf.sample.
+#enable_service q-meta
+disable_service q-meta
+
 # Whether or not to build custom openvswitch kernel modules from the ovs git
 # tree. This is enabled by default.  This is required unless your distro kernel
 # includes ovs+conntrack support.  This support was first released in Linux 4.3,
 # and will likely be backported by some distros.
 #OVN_BUILD_MODULES=False
 
-# If you enable the DHCP agent, configure it to provide a route for
-# metadata to instances.
-ENABLE_ISOLATED_METADATA=True
-
 # Enable QoS
 #enable_plugin neutron http://git.openstack.org/openstack/neutron
 #enable_service q-qos

doc/source/features.rst

@@ -15,7 +15,7 @@ services:
 
   Native implementation or conventional layer-3 agent. The native
   implementation supports distributed routing. However, it currently lacks
-  support for floating IP addresses and NAT.
+  support for floating IP addresses, NAT, and the metadata proxy.
 
 * DHCP
 

releasenotes/notes/networking-ovn-0df373f5a7b22d19.yaml

@@ -1,45 +1,61 @@
 ---
 features:
   - |
-    This is the initial release of OpenStack neutron integration with OVN.
-    OVN provides virtual networking for Open vSwitch and is a component of
-    the `Open vSwitch <http://openvswitch.org/>`_ project. The following
-    virtual networking features are available. Some features are provided
-    via a native OVN implementation or via a conventional neutron agent.
+    Initial release of the OpenStack Networking service (neutron)
+    integration with Open Virtual Network (OVN), a component of the
+    the `Open vSwitch <http://openvswitch.org/>`_ project. OVN provides
+    the following features either via native implementation or
+    conventional agents:
 
-    * Layer-2 switching (native OVN implementation)
-    * Layer-3 routing (native OVN implementation or conventional
-      neutron layer-3 agent) The native OVN implementation supports
-      distributed routing. However, it currently lacks support for
-      floating IP addresses and NAT.
-    * DHCP (native OVN implementation or conventional neuron DHCP agent)
+    * Layer-2 (native OVN implementation)
+    * Layer-3 (native OVN implementation or conventional layer-3 agent)
+      The native OVN implementation supports distributed routing. However,
+      it currently lacks support for floating IP addresses, NAT, and the
+      metadata proxy.
+    * DHCP (native OVN implementation or conventional DHCP agent)
       The native implementation supports distributed DHCP. However,
-      it currently lacks IPv6 support and support for the Neutron
-      internal DNS and metadata proxy features.
-    * Metadata (conventional neutron metadata agent)
-    * DPDK - May be used with OVS using either the Linux kernel
-      datapath or the DPDK datapath.
+      it currently lacks support for IPv6, internal DNS, and metadata
+      proxy.
+    * Metadata (conventional metadata agent)
+    * DPDK - Usable with OVS via either the Linux kernel datapath
+      or the DPDK datapath.
 
-    The initial release also supports the following neutron API
-    extensions, ``agent``, ``Address Scopes`` \*,
-    ``Allowed Address Pairs``, ``Auto Allocated Topology Services``,
-    ``Availability Zone``, ``Default Subnetpools``,
-    ``DHCP Agent Scheduler`` \*\*, ``Distributed Virtual Router`` \*,
-    ``DNS Integration`` \*, ``HA Router extension`` \*,
-    ``L3 Agent Scheduler`` \*,
-    ``Network Availability Zone`` \*\*, ``Network IP Availability``,
-    ``Neutron external network``, ``Neutron Extra DHCP opts``,
-    ``Neutron Extra Route``,
-    ``Neutron L3 Configurable external gateway mode`` \*,
-    ``Neutron L3 Router``,
-    ``Network MTU``, ``Port Binding``, ``Port Security``,
-    ``Provider Network``, ``Quality of Service``,
-    ``Quota management support``, ``RBAC Policies``,
-    ``Resource revision numbers``,
-    ``Router Availability Zone`` \*, ``security-group``,
-    ``standard-attr-description``, ``Subnet Allocation``,
-    ``Tag support`` and ``Time Stamp Fields``.
+    The initial release also supports the following Networking service
+    API extensions:
 
-    (\*) Only applicable when conventional neutron layer-3 agent enabled.
+    * ``agent``
+    * ``Address Scopes`` \*
+    * ``Allowed Address Pairs``
+    * ``Auto Allocated Topology Services``
+    * ``Availability Zone``
+    * ``Default Subnetpools``
+    * ``DHCP Agent Scheduler`` \*\*
+    * ``Distributed Virtual Router`` \*
+    * ``DNS Integration`` \*
+    * ``HA Router extension`` \*
+    * ``L3 Agent Scheduler`` \*
+    * ``Network Availability Zone`` \*\*
+    * ``Network IP Availability``
+    * ``Neutron external network``
+    * ``Neutron Extra DHCP opts``
+    * ``Neutron Extra Route``
+    * ``Neutron L3 Configurable external gateway mode`` \*
+    * ``Neutron L3 Router``
+    * ``Network MTU``
+    * ``Port Binding``
+    * ``Port Security``
+    * ``Provider Network``
+    * ``Quality of Service``
+    * ``Quota management support``
+    * ``RBAC Policies``
+    * ``Resource revision numbers``
+    * ``Router Availability Zone`` \*
+    * ``security-group``
+    * ``standard-attr-description``
+    * ``Subnet Allocation``
+    * ``Tag support``
+    * ``Time Stamp Fields``
 
-    (\*\*) Only applicable when conventional DHCP agent enabled.
+    (\*) Only applicable if using the conventional layer-3 agent.
+
+    (\*\*) Only applicable if using the conventional DHCP agent.

vagrant/provisioning/setup-compute.sh

@@ -31,7 +31,9 @@ OVN_NB_REMOTE=tcp:$OVN_DB_IP:6641
 LOGFILE=/opt/stack/log/stack.sh.log
 SCREEN_LOGDIR=/opt/stack/log/data
 
-# Enable the DHCP and metadata services on the compute node.
+# Disable the OVN native DHCP service and enable the conventional DHCP and
+# metadata agents on the compute node.
+OVN_NATIVE_DHCP=False
 enable_service q-dhcp q-meta
 
 # Use provider network for public.

vagrant/provisioning/setup-controller.sh

@@ -42,8 +42,10 @@ disable_service ovn-northd
 # on the controller node that depend on it.
 disable_service ovn-controller
 
-# Disable the DHCP and metadata services on the controller node because the
-# architecture only deploys them on separate compute nodes.
+# Disable the OVN native DHCP service and conventional DHCP and metadata
+# agents on the controller node because the architecture deploys them on
+# compute nodes.
+OVN_NATIVE_DHCP=False
 disable_service q-dhcp q-meta
 
 # Disable the nova compute service on the controller node because the
@@ -86,6 +88,13 @@ cat << 'DEVSTACKEOF' >> devstack/local.conf
 network_scheduler_driver = neutron.scheduler.dhcp_agent_scheduler.AZAwareWeightScheduler
 dhcp_load_type = networks
 dhcp_agents_per_network = 2
+
+# Configure the Compute service (nova) metadata API to use the X-Forwarded-For
+# header sent by the Networking service metadata proxies on the compute nodes.
+
+[[post-config|$NOVA_CONF]]
+[DEFAULT]
+use_forwarded_for = True
 DEVSTACKEOF
 
 devstack/stack.sh