Nice diagrams. :-) Thanks. Susanne On Mon, Oct 13, 2014 at 4:18 PM, Phillip Toohill < phillip.tooh...@rackspace.com> wrote:
> Diagrams in jpeg format.. > > On 10/12/14 10:06 PM, "Phillip Toohill" <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 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> 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@lists.openstack.org > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >>_______________________________________________ > >>OpenStack-dev mailing list > >>OpenStack-dev@lists.openstack.org > >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > >_______________________________________________ > >OpenStack-dev mailing list > >OpenStack-dev@lists.openstack.org > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev