<div dir="ltr">Hi Brandon,<div><br></div><div>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.</div>
<div><br></div><div>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:</div><div><br></div><div>1. Use the existing neutron LBaaS API, with the backend being the existing neutron LBaaS db schema. This is the status quo.</div>
<div>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 (<a href="https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst" target="_blank" style="font-size:13px;font-family:arial,sans-serif">https://review.openstack.org/#/c/89903/5/specs/juno/<span class="">lbaas</span>-api-and-objmodel-improvement.rst</a>) should be implemented for this new LBaaS service, post reviews.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div><br></div><div>Regards,</div><div>Vijay</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 27, 2014 at 12:32 PM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Referencing this blueprint:<br>
<a href="https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst" target="_blank">https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst</a><br>
<br>
Anyone who has suggestions to possible issues or can answer some of<br>
these questions please respond.<br>
<br>
<br>
1. LoadBalancer to Listener relationship M:N vs 1:N<br>
The main reason we went with the M:N was so IPv6 could use the same<br>
listener as IPv4. However this can be accomplished by the user just<br>
creating a second listener and pool with the same configuration. This<br>
will end up being a bad user experience when the listener and pool<br>
configuration starts getting complex (adding in TLS, health monitors,<br>
SNI, etc). A good reason to not do the M:N is because the logic on might<br>
get complex when dealing with status. I'd like to get people's opinions<br>
on this on whether we should do M:N or just 1:N. Another option, is to<br>
just implement 1:N right now and later implement the M:N in another<br>
blueprint if it is decided that the user experience suffers greatly.<br>
<br>
My opinion: I like the idea of leaving it to another blueprint to<br>
implement. However, we would need to watch out for any major<br>
architecture changes in the time itis not implemented that could make<br>
this more difficult than what it needs to be.<br>
<br>
2. Pool to Health Monitor relationship 1:N vs 1:1<br>
Currently, I believe this is 1:N however it was suggested to deprecate<br>
this in favor of 1:1 by Susanne and Kyle agreed. Are there any<br>
objections to channging to 1:1?<br>
<br>
My opinion: I'm for 1:1 as long as there aren't any major reasons why<br>
there needs to be 1:N.<br>
<br>
3. Does the Pool object need a status field now that it is a pure<br>
logical object?<br>
<br>
My opinion: I don't think it needs the status field. I think the<br>
LoadBalancer object may be the only thing that needs a status, other<br>
than the pool members for health monitoring. I might be corrected on<br>
this though.<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>
</blockquote></div><br></div></div>