Open Stack

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_create.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