Open Stack

Hi,
Happy you asked about this. This is an idea that we have:

Below is a suggestion on how we can improve the metadata service. This can
be done by leveraging the a Load balancers supports X-Forwarded-For.The
following link has two diagrams. The first is the existing support (may be
a little rusty here, so please feel free to correct) and the second is the
proposal. 
https://docs.google.com/drawings/d/19JCirhj2NVVFZ0Vbnsxhyxrm1jjzEAS3ZAMzfBR
C-0E/edit?usp=sharing

Metadata proxy support: the proxy will receive the HTTP request. It will
then perform a query to the Neutron service (1) to retrieve the tenant id
and the instance id from the neutron service. A proxy request will be sent
to Nova for the metadata details (2).

Proposed support:

1. There will be a load balancer vip ­ 254.169.254.169 (this can be
reached either via the L3 agent of the DG on the DHCP.
2. The LB will have a server farm of all of the Nova API's (this makes the
soon highly available)
     1. Replace the destination IP and port with the Nova metadata IP and
port
     2. Replace the source IP with the interface IP
     3. Insert the header X-Fowarded-For (this will have the original
source IP of the VM)



1. When the Nova metadata service receives the request, according to a
configuration variable
(https://github.com/openstack/nova/blob/master/nova/api/metadata/handler.py
#L134), will interface with the neutron service to get the instance_id and
the tenant id. This will be done by using a new extension. With the
details provided by Neutron Nova will provide the correct metadata for the
instance
2. A new extension will be added to Neutron that will enable a port
lookup. The port lookup will have two input values and will return the
port ­ which has the instance id and the tenant id.
1. LB source IP ­ this is the LB source IP that interfaces with the Nova
API. When we create the edge router for the virtual network we will have a
mapping of the edge LB ip <-> network id. This will enable us to get the
virtual network for the port
2. Fixed port IP ­ this with the virtual network will enable us to get the
specific port.

Hopefully in the coming days a spec will be posted that will provide more
details

Thanks
Gary



On 8/1/14, 6:11 PM, "marios at redhat.com" <mandreou at redhat.com> wrote:

>Hi all,
>
>I have been asked by a colleague about the status of A/A HA for
>neutron-* processes. From the 'HA guide' [1], l3-agent and
>metadata-agent are the only neutron components that can't be deployed in
>A/A HA (corosync/pacemaker for a/p is documented as available 'out of
>the box' for both).
>
>The l3-agent work is approved for J3 [4] but I am unaware of any work on
>the metadata-agent and can't see any mention in [2][3]. Is this someone
>has looked at, or is planning to (though ultimately K would be the
>earliest right?)?
>
>thanks! marios
>
>[1] http://docs.openstack.org/high-availability-guide/content/index.html
>[2] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan
>[3] 
>https://urldefense.proofpoint.com/v1/url?u=https://launchpad.net/neutron/%
>2Bmilestone/juno-3&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6h
>goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=TZXQIMHmAX22lC0YOyItiXOrAA%2FegHqY5cN
>I73%2B0jJ8%3D%0A&s=b81f4d5919b317628f56d0313143cee8fca6e47f639a59784eb19da
>3d88681da
>[4]
>http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/l3-h
>igh-availability.rst
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev