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:sleipnir...@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.tooh...@rackspace.com<mailto:phillip.tooh...@rackspace.com>> wrote: Diagrams in jpeg format.. On 10/12/14 10:06 PM, "Phillip Toohill" <phillip.tooh...@rackspace.com<mailto:phillip.tooh...@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.lo...@rackspace.com<mailto:brandon.lo...@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 >>> OpenStackemail@example.com<mailto:OpenStackfirstname.lastname@example.org> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>_______________________________________________ >>OpenStack-dev mailing list >>OpenStackemail@example.com<mailto:OpenStackfirstname.lastname@example.org> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >_______________________________________________ >OpenStack-dev mailing list >OpenStackemail@example.com<mailto:OpenStackfirstname.lastname@example.org> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com<mailto:OpenStackfirstname.lastname@example.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev