Open Stack

On 03/08/14 13:07, Gary Kotton wrote:
> 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 for that info Gary, the diagram in particular forced me to go
read a bit about the metadata agent (i was mostly just proxying for the
original question). I obviously miss a lot of the details (will be
easier once the spec is out) but it seems like you're proposing an
addition (port-lookup) that will change the way the metadata agent is
called; in fact does it make the neutron metadata proxy obsolete? I will
keep a look out for the spec,

thanks, marios



> 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
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>