Per the IRC discussion this morning, I believe it was decided that we would prioritize creating a v2 agent which should run in parallel with the v1 agent. Further, for any subsequent driver shim layer, this should happen after the v2 agent is functional.
... or I may have misunderstood what was decided in the meeting. :) In any case, y'all should feel free to correct me here and/or raise other concerns we didn't think about, eh! Stephen On Wed, Jul 9, 2014 at 3:12 PM, Brandon Logan <brandon.lo...@rackspace.com> wrote: > Shim will become quite complicated due to the fact we won't be able to > actually send any load balancer information to the driver until a load > balancer is linked to a listener, pool, and member. The reason is because > for a vip to be created it needs attributes from a load balancer and > listener. A vip also has a required attribute of pool_id in the old API so > all the old driver are expecting a pool_id. So this means we need a pool > first. Since the subnet_id has been moved off the pool and onto the pool > member, we will need to have a pool with at least one member before we can > send all that information to the driver. > > Now once that is done, it will probably get even crazier with updates and > deletes to each one of those entities. > > So should time and effort be spent on the shim, which is temporary and > eventually thrown away. Or should time be spent on creating a new version > of the agent and namspace driver based off the new driver interface, which > will need to be done anyway? > > Doing the shim could end up being faster than creating a new version of > the agent, but since there are going to be a lot of crazy edge cases, I > question the stability of it and the time it may take for it to become > stable. > > One problem with not doing the shim is the older drivers cannot be used > with the new API and will have to be updated. To this, I would argue that > there is no benefit to using the new API with an old driver versus using > the Old API with the old driver, right now. Once L7 and TLS get in then > yes there would be. > > I'd just like to get people's ideas on this. > > Thanks, > Brandon > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev