Open Stack

Nice diagrams. :-) Thanks. Susanne

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

> 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/20141014/140ef2ae/attachment.html>