Open Stack

Thanks for the doc.

The floating IP could be hosted directly by the lb backend/lb appliance as well?
It depends on the appliance deployment.

From: Susanne Balle [mailto:sleipnir012 at gmail.com]
Sent: 14 October 2014 21:15
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Nice diagrams. :-) Thanks. Susanne

On Mon, Oct 13, 2014 at 4:18 PM, Phillip Toohill <phillip.toohill at rackspace.com<mailto:phillip.toohill at rackspace.com>> wrote:
Diagrams in jpeg format..

On 10/12/14 10:06 PM, "Phillip Toohill" <phillip.toohill at RACKSPACE.COM<mailto:phillip.toohill at RACKSPACE.COM>>
wrote:

>Hello all,
>
>Heres some additional diagrams and docs. Not incredibly detailed, but
>should get the point across.
>
>Feel free to edit if needed.
>
>Once we come to some kind of agreement and understanding I can rewrite
>these more to be thorough and get them in a more official place. Also, I
>understand theres other use cases not shown in the initial docs, so this
>is a good time to collaborate to make this more thought out.
>
>Please feel free to ping me with any questions,
>
>Thank you
>
>
>Google DOCS link for FLIP folder:
>https://drive.google.com/folderview?id=0B2r4apUP7uPwU1FWUjJBN0NMbWM&usp=sh
>a
>ring
>
>-diagrams are draw.io<http://draw.io> based and can be opened from within Drive by
>selecting the appropriate application.
>
>On 10/7/14 2:25 PM, "Brandon Logan" <brandon.logan at RACKSPACE.COM<mailto:brandon.logan at RACKSPACE.COM>> wrote:
>
>>I'll add some more info to this as well:
>>
>>Neutron LBaaS creates the neutron port for the VIP in the plugin layer
>>before drivers ever have any control.  In the case of an async driver,
>>it will then call the driver's create method, and then return to the
>>user the vip info.  This means the user will know the VIP before the
>>driver even finishes creating the load balancer.
>>
>>So if Octavia is just going to create a floating IP and then associate
>>that floating IP to the neutron port, there is the problem of the user
>>not ever seeing the correct VIP (which would be the floating iP).
>>
>>So really, we need to have a very detailed discussion on what the
>>options are for us to get this to work for those of us intending to use
>>floating ips as VIPs while also working for those only requiring a
>>neutron port.  I'm pretty sure this will require changing the way V2
>>behaves, but there's more discussion points needed on that.  Luckily, V2
>>is in a feature branch and not merged into Neutron master, so we can
>>change it pretty easily.  Phil and I will bring this up in the meeting
>>tomorrow, which may lead to a meeting topic in the neutron lbaas
>>meeting.
>>
>>Thanks,
>>Brandon
>>
>>
>>On Mon, 2014-10-06 at 17:40 +0000, Phillip Toohill wrote:
>>> Hello All,
>>>
>>> I wanted to start a discussion on floating IP management and ultimately
>>> decide how the LBaaS group wants to handle the association.
>>>
>>> There is a need to utilize floating IPs(FLIP) and its API calls to
>>> associate a FLIP to the neutron port that we currently spin up.
>>>
>>> See DOCS here:
>>>
>>> >
>>>http://docs.openstack.org/api/openstack-network/2.0/content/floatingip_c
>>>r
>>>eate.html
>>>
>>> Currently, LBaaS will make internal service calls (clean interface :/)
>>>to create and attach a Neutron port.
>>> The VIP from this port is added to the Loadbalancer object of the Load
>>>balancer configuration and returned to the user.
>>>
>>> This creates a bit of a problem if we want to associate a FLIP with the
>>>port and display the FLIP to the user instead of
>>> the ports VIP because the port is currently created and attached in the
>>>plugin and there is no code anywhere to handle the FLIP
>>> association.
>>>
>>> To keep this short and to the point:
>>>
>>> We need to discuss where and how we want to handle this association. I
>>>have a few questions to start it off.
>>>
>>> Do we want to add logic in the plugin to call the FLIP association API?
>>>
>>> If we have logic in the plugin should we have configuration that
>>>identifies weather to use/return the FLIP instead the port VIP?
>>>
>>> Would we rather have logic for FLIP association in the drivers?
>>>
>>> If logic is in the drivers would we still return the port VIP to the
>>>user then later overwrite it with the FLIP?
>>> Or would we have configuration to not return the port VIP initially,
>>>but an additional query would show the associated FLIP.
>>>
>>>
>>> Is there an internal service call for this, and if so would we use it
>>>instead of API calls?
>>>
>>>
>>> Theres plenty of other thoughts and questions to be asked and discussed
>>>in regards to FLIP handling,
>>> hopefully this will get us going. I'm certain I may not be completely
>>>understanding this and
>>> is the hopes of this email to clarify any uncertainties.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org<mailto: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<mailto: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<mailto: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<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141015/a98be8e3/attachment.html>