Open Stack

Diagrams in jpeg format..

On 10/12/14 10:06 PM, "Phillip Toohill" <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 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> 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
>>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: FLIP S1.jpg
Type: image/jpeg
Size: 58225 bytes
Desc: FLIP S1.jpg
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141013/8c585bde/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FLIP S2.jpg
Type: image/jpeg
Size: 50988 bytes
Desc: FLIP S2.jpg
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141013/8c585bde/attachment-0001.jpg>