Open Stack

On 8/4/14, 5:39 PM, "marios at redhat.com" <mandreou at redhat.com> wrote:

>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://urldefense.proofpoint.com/v1/url?u=https://docs.google.com/drawin
>>gs/d/19JCirhj2NVVFZ0Vbnsxhyxrm1jjzEAS3ZAMzfBR&k=oIvRg1%2BdGAgOoM1BIlLLqw%
>>3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=pDHtkey4
>>U%2FmCkIGoEa0vUaWK4o93GK5Ep2QhTvy2gAw%3D%0A&s=98f30ec826fdd475b3ecca4a22b
>>a6d3664652d7281a1a95b88eba9de570cc678
>> 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://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack/
>>nova/blob/master/nova/api/metadata/handler.py&k=oIvRg1%2BdGAgOoM1BIlLLqw%
>>3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=pDHtkey4
>>U%2FmCkIGoEa0vUaWK4o93GK5Ep2QhTvy2gAw%3D%0A&s=5f11211dd96938ae5a319c12eb6
>>e01f9fa585d76aa5ee6a36a96561644fbb625
>> #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,

At the moment there is already a port lookup. This is done by the metadata
proxy.
The proposed solution will have less hops and fewer elements that can
fail. Hopefully we
Can get the spec posted in the near future. Sadly this will not be
approved for Juno.

>
>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=eH0pxTUZo8NPZyF
>>>6h
>>> 
>>>goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=TZXQIMHmAX22lC0YOyItiXOrAA%2FegHqY5
>>>cN
>>> 
>>>I73%2B0jJ8%3D%0A&s=b81f4d5919b317628f56d0313143cee8fca6e47f639a59784eb19
>>>da
>>> 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
>> 
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev