Metadata Access in OVN without l3/dhcp agents

[Ramu Ramamurthy]

Problem:

VMs access the neutron metadata service available at the link-local IP address: 169.254.169.254.
We want to implement the metadata service in networking-ovn without running DHCP or L3 agents.

A flow for metadata access is the following:
VM---(169.254.169.254:80)---->metadata-proxy----unix socket---->metadata-agent---->nova

This is implemented in neutron in one of the following 2 ways:

1) DHCP agent-based for isolated networks using the dhcp-namespace

In isolated networks (without a router), the DHCP agent does the following
a) The dhcp port in the DHCP namespace is aliased with the metadata server IP address
b) the dhcp agent adds a static route to 169.254.169.254 to point to the dhcp port in dhcp transactions with VMs,
This is done using the dhcp static route option (249)
c) the metadata-proxy runs in the dhcp namespace

2) L3-agent based using the router-namespace
The metadata proxy runs in router namespace. Iptables (input, nat and filter) rules
redirect metadata traffic to the metadata proxy.

[Ramu Ramamurthy (ramu-ramamurthy)]

An approach has been posted at the ovs dev mailing list for discussion

http://openvswitch.org/pipermail/dev/2016-April/069390.html

[Ramu Ramamurthy (ramu-ramamurthy)]

Please refer to the discussion here:

http://openvswitch.org/pipermail/dev/2016-April/069390.html

The proposed flow for ovn metadata access without any neutron-dhcp-agent
 or neutron-l3-agent is as follows.

VM —(http://169.254.169.254)—> neutron-metatadata-proxy—unix socket—> ovn-metadata—>nova

neutron-ovn-plugin does the following:

* creates a “dhcp-port” upon subnet creation
* Sets the type of the dhcp-port to “distributed”
* Sets the options “device_id”, “tenant_id”,”ipv4”, and “network-id” on each Logical Port

A new ovn-metadata service runs on each hypervisor.
The ovn-metadata service is not a "neutron-agent", and does the following:

* monitors the ovsdb interface table
    * when a new “distributed” port is created by ovn-controller
        * creates a network namespace, and a spawns the neutron-metadata-proxy process within that namespace
        * The neutron-metadata-proxy process receives the http metadata request from the VM, and forwards it to
           the ovn-metadata service via the unix socket after adding 2 http headers
* Listens on the “metadata-proxy” unix socket
    * Upon a http request from the neutron-metadata-proxy on the unix socket - extracts X-Forwarded-For, and X-Network-Id from the http-request, Then, based on these, extracts the “device_id”, and “tenant_id” from the external-ids on the ovs-interface corresponding to the VM
    * Forwards the http request to nova

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/315305

[OpenStack Infra (hudson-openstack)]

Change abandoned by Ramu Ramamurthy (<email address hidden>) on branch: master
Review: https://review.openstack.org/315305
Reason: Abandoning this.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/452811

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/452811
Committed: https://git.openstack.org/cgit/openstack/networking-ovn/commit/?id=928ac9e399f5a23f950e046d7317de3482a05679
Submitter: Jenkins
Branch: master

commit 928ac9e399f5a23f950e046d7317de3482a05679
Author: Russell Bryant <email address hidden>
Date: Mon Apr 3 11:43:51 2017 -0400

    Proposed support for Metadata API.

    This document describes a proposed approach for supporting the OpenStack
    Metadata API with networking-ovn.

    Change-Id: I3dfed21743e84247f4269f3c67c06571c1d11b94
    Co-authored-by: Daniel Alvarez <email address hidden>
    Related-bug: #1562132

[Daniel Alvarez (dalvarezs)]

Fix released: https://review.openstack.org/#/c/471140/