Hi Bo-- Haproxy is able to have IPv4 front-ends with IPv6 back-ends (and visa versa) because it actually initiates a separate TCP connection between the front end client and the back-end server. The front-end thinks haproxy is the server, and the back-end thinks haproxy is the client. In practice, therefore, its totally possible to have an IPv6 front-end and IPv4 back-end with haproxy (for both http and generic TCP service types).
I think this is similarly true for vendor appliances that are capable of doing IPv6, and are also initiating new TCP connections from the appliance to the back-end. Obviously, the above won't work if your load balancer implementation is doing something "transparent" on the network layer like LVM load balancing. Stephen On Wed, May 28, 2014 at 9:14 PM, Bo Lin <l...@vmware.com> wrote: > Hi Brandon, > I have one question. If we support LoadBalancer to Listener relationship > M:N, then one listener with IPV4 service members backend may be shared by a > loadbalancer instance with IPV6 forntend. Does it mean we also need to > provide IPV6 - IPV4 port forwarding functions in LBaaS services products? > Does iptables or most LBaaS services products such as haproxy or so on > provide such function? Or I am just wrong in some technique details on > these LBaaS products. > > Thanks! > ------------------------------ > *From: *"Vijay B" <os.v...@gmail.com> > > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > *Sent: *Thursday, May 29, 2014 6:18:42 AM > > *Subject: *Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in > object model refactor blueprint > > Hi Brandon! > > Please see inline.. > > > > > On Wed, May 28, 2014 at 12:01 PM, Brandon Logan < > brandon.lo...@rackspace.com> wrote: > >> Hi Vijay, >> >> On Tue, 2014-05-27 at 16:27 -0700, Vijay B wrote: >> > Hi Brandon, >> > >> > >> > The current reviews of the schema itself are absolutely valid and >> > necessary, and must go on. However, the place of implementation of >> > this schema needs to be clarified. Rather than make any changes >> > whatsoever to the existing neutron db schema for LBaaS, this new db >> > schema outlined needs to be implemented for a separate LBaaS core >> > service. >> > >> Are you suggesting a separate lbaas database from the neutron database? >> If not, then I could use some clarification. If so, I'd advocate against >> that right now because there's just too many things that would need to >> be changed. Later, when LBaaS becomes its own service then yeah that >> will need to happen. >> > > v> Ok, so as I understand it, in this scheme, there is no new schema or > db, there will be a new set of tables resident in neutron_db schema itself, > alongside legacy lbaas tables. Let's consider a rough view of the > implementation. > > Layer 1 - We'll have a new lbaas v3.0 api in neutron, with the current > lbaas service plugin having to support it in addition to the legacy lbaas > extensions that it already supports. We'll need to put in new code anyway > that will process the v3.0 lbaas api no matter what our approach is. > Layer 2 - Management code that will take care of updating the db with > entities in pending_create, then invoking the right provider driver, > choosing/scheduling the plugin drivers or the agent drivers, invoking them, > getting the results, and updating the db. > Layer 3 - The drivers themselves (either plugin drivers (like the HAProxy > namespace driver/Netscaler) or plugin drivers + agent drivers). > > While having the new tables sit alongside the legacy tables is one way to > implement the changes, I don't see how this approach leads to a lesser > amount of changes overall. Layer 2 above will be the major place where > changes can be complicated. Also, it will be confusing to have two sets of > lbaas tables in the same schema. > > I don't want a separate lbaas database under neutron, and neither do I > want it within neutron. I'm not suggesting that we create a db schema > alone, I'm saying we must build it with the new LBaaS service (just like > neutron itself when it got created). If we don't do this now, we'll end up > reimplementing the logic implemented in neutron for the new lbaas v3.0 API > all over again for the new core LBaaS service. We'd rather do it in the new > one in one effort. > > I could be missing some constraints that drive taking the former approach > - please help me understand those - I don't want to be discounting any one > approach without thorough consideration. Right now, it looks to me like > this approach is being taken only to accommodate the HAProxy namespace > driver. Really that is the only driver which seems to be very intertwined > with neutron in the way it uses namespaces. > > > > >> > What we should be providing in neutron is a switch (a global conf) >> > that can be set to instruct neutron to do one of two things: >> > >> > >> > 1. Use the existing neutron LBaaS API, with the backend being the >> > existing neutron LBaaS db schema. This is the status quo. >> > 2. Use the existing neutron LBaaS API, with the backend being the new >> > LBaaS service. This will invoke calls not to neutron's current LBaaS >> > code at all, rather, it will call into a new set of proxy "backend" >> > code in neutron that will translate the older LBaaS API calls into the >> > newer REST calls serviced by the new LBaaS service, which will write >> > down these details accordingly in its new db schema. As long as the >> > request and response objects to legacy neutron LBaaS calls are >> > preserved as is, there should be no issues. Writing unit tests should >> > also be comparatively more straightforward, and old functional tests >> > can be retained, and newer ones will not clash with legacy code. >> > Legacy code itself will work, having not been touched at all. The >> > blueprint for the db schema that you have referenced >> > ( >> https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst >> <https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=800daa0d65da46080d85d59d01555839dbdc8e97558ba7029f1f440d993bc8c3>) >> should be implemented for this new LBaaS service, post reviews. >> > >> I think the point of this blueprint is to get the API and object model >> less confusing for the Neutron LBaaS service plugin. I think it's too >> early to create an LBaaS service because we have not yet cleaned up the >> tight integration points between Neutron LBaaS and LBaaS. Creating a >> new service would require only API interactions between Neutron and this >> LBaaS service, which currently is not possible due to these tight >> integration points. >> > > v> The tight integration points between LBaaS and neutron that I see are: > > 1. The usage of namespaces. > 2. L2 and L3 plumbing within the namespaces and tracking them in the > neutron and lbaas tables, > 3. Plugin driver and agent driver scheduling framework/mechanism for LB > drivers. > 4. The way drivers directly update the neutron db, which I think makes for > a lack of clear functional demarcation. > > Regardless of how we use the new API and db model, will namespaces be > used? If they still need to be supported, the tight integration isn't going > to go anywhere. > > This is why I think it will be best to keep the legacy drivers within > neutron, and not give an option to newer deployments to use that > concurrently with the new lbaas core service. The changes will be lesser > this way because we won't touch legacy code. > > While I fully understand that we're trying to change the way we look at > the lbaas deployments, and the db object model is an effort towards that, > we need to ensure that the execution is kept elegant as well. For drivers > for lb solutions like f5 or Netscaler, these pain points can be done away > with because they do their own network provisioning and we keep track of > them only to clean up (especially for virtual appliance solutions). > > It will however mean that we'll have the additional task of implementing > the new core service before we can use the new db object model. I say we > should just go for that effort and make it happen. > > > >> > >> > The third option would be to turn off neutron LBaaS API, and use the >> > new LBaaS core service directly, but for this we can simply disable >> > neutron lbaas, and don't need a config parameter in neutron. >> > >> > >> > Implementing this db schema within neutron instead will be not just >> > complicated, but a huge effort that will go waste in future once the >> > new LBaaS service is implemented. Also, migration will unnecessarily >> > retain the same steps needed to go from legacy neutron LBaaS to the >> > new core LBaaS service in this approach (twice, in succession) in case >> > for any reason the version goes from legacy neutron LBaaS -> new >> > neutron LBaaS -> new LBaaS core service. >> I totally agree that this is technical debt, but I believe it is the >> best option we have right now since LBaaS needs to live in the Neutron >> code and process because of the tight integration points. Since this >> object model refactor has been slated for Juno, and these tight >> integration points may or may not be cleaned up by Juno, staying within >> Neutron seems to be the best option right now. >> > > v> As I described above, I think the tight integration points are best > kept in legacy code and not carried over to the new implementation. The > cleanest way to do it would be to clearly demarcate neutron related > operations (L2/L3) from LBaaS. But I am keen to get your views on what the > difficult integration points are so that I get a better understanding of > the motivations behind keeping the new tables in neutron. > > > Regards, > Vijay > > > > >> > >> > Going forward, the legacy neutron LBaaS API can be deprecated, and the >> > new API that directly contacts the new LBaaS core service can be used. >> > >> > >> > We have discussed the above architecture previously, but outside of >> > the ML, and a draft of the blueprint for this new LBaaS core service >> > is underway, and is a collation of all the discussions among a large >> > number of LBaaS engineers including yourself during the summit - I >> > will be posting it for review within a couple of days, as planned. >> > >> > >> > >> > >> > Regards, >> > Vijay >> > >> > >> > On Tue, May 27, 2014 at 12:32 PM, Brandon Logan >> > <brandon.lo...@rackspace.com> wrote: >> > Referencing this blueprint: >> > >> https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst >> <https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=800daa0d65da46080d85d59d01555839dbdc8e97558ba7029f1f440d993bc8c3> >> > >> > Anyone who has suggestions to possible issues or can answer >> > some of >> > these questions please respond. >> > >> > >> > 1. LoadBalancer to Listener relationship M:N vs 1:N >> > The main reason we went with the M:N was so IPv6 could use the >> > same >> > listener as IPv4. However this can be accomplished by the >> > user just >> > creating a second listener and pool with the same >> > configuration. This >> > will end up being a bad user experience when the listener and >> > pool >> > configuration starts getting complex (adding in TLS, health >> > monitors, >> > SNI, etc). A good reason to not do the M:N is because the >> > logic on might >> > get complex when dealing with status. I'd like to get >> > people's opinions >> > on this on whether we should do M:N or just 1:N. Another >> > option, is to >> > just implement 1:N right now and later implement the M:N in >> > another >> > blueprint if it is decided that the user experience suffers >> > greatly. >> > >> > My opinion: I like the idea of leaving it to another blueprint >> > to >> > implement. However, we would need to watch out for any major >> > architecture changes in the time itis not implemented that >> > could make >> > this more difficult than what it needs to be. >> > >> > 2. Pool to Health Monitor relationship 1:N vs 1:1 >> > Currently, I believe this is 1:N however it was suggested to >> > deprecate >> > this in favor of 1:1 by Susanne and Kyle agreed. Are there >> > any >> > objections to channging to 1:1? >> > >> > My opinion: I'm for 1:1 as long as there aren't any major >> > reasons why >> > there needs to be 1:N. >> > >> > 3. Does the Pool object need a status field now that it is a >> > pure >> > logical object? >> > >> > My opinion: I don't think it needs the status field. I think >> > the >> > LoadBalancer object may be the only thing that needs a status, >> > other >> > than the pool members for health monitoring. I might be >> > corrected on >> > this though. >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=ec3a8e21156d1b946db652fac0dab2e2268340aea37bd8c30adbf52fe2f3e8de> >> > >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=ec3a8e21156d1b946db652fac0dab2e2268340aea37bd8c30adbf52fe2f3e8de> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=ec3a8e21156d1b946db652fac0dab2e2268340aea37bd8c30adbf52fe2f3e8de> >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > > https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=ec3a8e21156d1b946db652fac0dab2e2268340aea37bd8c30adbf52fe2f3e8de > > > _______________________________________________ > 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