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