Open Stack

Hi Vijay,

On Wed, 2014-05-28 at 15:18 -0700, Vijay B wrote:
> Hi Brandon!
> 
> 
> Please see inline..
> 
> 
> 
> 
> 
> 
> On Wed, May 28, 2014 at 12:01 PM, Brandon Logan
> <brandon.logan at 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.

Yes that is how I understand it as well.

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

That is the gist of it as I understand it.

> 
> 
> 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 agree, with the goal being LBaaS becoming its own service later, it is
definitely more changes to do it this way.  This way was just the
process agreed on at the Summit because it was less disruptive and
easier to accomplish with the expectation that LBaaS still will still
reside in Neutron in Juno.  Some time after Juno is when it was decided
to be spun out, which is when I suppose we would actually create the
LBaaS service you're talking about.  Those details weren't discussed
though, so I could just be interpreting it my own way.

> 
> 
> 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 believe everyone would rather not do the same thing twice but to meet
the needs of Neutron and LBaaS it was agreed that this would be the way
to do it.  At least that is my understanding, someone please correct me
if I'm wrong.

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

No, I don't think its even considering the namespace driver.  In my very
limited time at looking at that code I didn't think the namespaces were
a dependency on Neutron, but I may have missed the dependency there.  My
understanding of one of the tight integration points was some drivers
actually querying/updating the neutron database.  That is obviously
something that needs to be fixed though.  

> 
> 
> 
> 
>         >
>         > 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) 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.
I'm not so sure about this one, but I could be wrong because I haven't
looked at that code in depth.
> 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.

For an operator level HaProxy driver I don't think namespaces will be
used, but that hasn't been fleshed out yet.  However, if anything comes
up that is a tight integration point with Neutron those will be need to
be fixed because the end goal is to have LBaaS as its own service.

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

Yeah that is another problem of going that route if it would ready by
Juno.  I'm not sure.

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

Kyle and Mark will be providing a list of those integration points soon.
Listing those and fixing those is another thing we agreed on at the
summit with the goal of this becoming its own service.

Will you be at the meeting tomorrow in IRC? I'd like to talk to you more
about this so we both can fully understand what we both mean.  I know I
am not explaining myself very well and I'm probably misunderstanding
what you are saying as well.  I'm interested in anything that gets this
process done easier and faster.  I agree with the approach for the LBaaS
standalone service, but I think going that route right now would go
against what we agreed on at the Summit.  I hope to catch you in IRC
tomorrow.

Thanks,
Brandon

> 
> 
> 
> 
> 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.logan at rackspace.com> wrote:
>         >         Referencing this blueprint:
>         >
>         https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst
>         >
>         >         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 at lists.openstack.org
>         >
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>         >
>         >
>         > _______________________________________________
>         > OpenStack-dev mailing list
>         > OpenStack-dev at lists.openstack.org
>         >
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>         
>         _______________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.org
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>         
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev