Open Stack

Hi ya'll!

Comments inline:


On Sun, Jun 1, 2014 at 1:09 PM, Brandon Logan <brandon.logan at rackspace.com>
wrote:

> Hi Eugene and Sam,
>
> On Sun, 2014-06-01 at 12:07 +0400, Eugene Nikanorov wrote:
> > Hi Sam,
> >
> >         Eugene, please comment on the migration process bellow.
> >
> >         I think that closing down the "status" handling should be done
> >         in phase 1.
> > I don't mind. If you're talking about provisioning status then such
> > status (if we're still going to maintain it per each kind of object)
> > goes to various associations: loadbalancer-listener, or
> > loadbalancer-listener-pool, etc.
> > Not a big deal of course, it was just my initial intent to limit phase
> > #1 as much as possible.
>
> I was hoping to limit it as well to keep it focused on just the
> refactoring portion.  I didn't want the scope to include all new
> features and changes under the sun.  It also makes reviewing much
> simpler.
>

I'm OK with limiting scope here so long as we don't implement something
that is effectively "forward compatible" with whatever we will probably
want to do in the future. (So, having a discussion around this is probably
worthwhile.)  To phrase this another way, what consumes the 'status'
information, and what do they really want to know?


>
> >
> >
> >         Missing to do so, will create tests and other depending
> >         workflows that assume the "current" status field, which will
> >         add  a technology debt to this new code.
> > I'd say it would depend on the strategy options you're suggestion
> > below.
> > As far as bw compatibility is concerned (if it's concerned at all), we
> > have to support existing status field, so that would not be any
> > additional debt.
> >
> >
> >         Migration and co-existence:
> >         I think that it would be better to have the new object model
> >         and API done in a way that does not "break" existing code, and
> >         then switch the "old" api to redirect to the "new" api.
> > Basically this means creating another lbaas plugin, that expose
> > existing lbaas api extension.
> > I'm not sure how this can be done considering the difference between
> > new proposed api and existing api.
> >
> >         This might be done in one of the two ways bellow:
> >         1. Rename all objects in the "new" api so you have a clear
> >         demarcation point. This might be sufficient.
> > I'm not sure how this could be done, can you explain?
> > I actually would consider changing the prefix to /v3/ to not to deal
> > with any renamings, that would require some minor refactoring on
> > extension framework side.
> His suggestion in the BP was to rename pool, healthmonitor, and member
> to group, healthcheck, and node respectively.  Since loadbalancer and
> listener are already new those don't have to be renamed.  This way the
> old object models and db tables remain intact and the old API can still
> function as before.
> >
> >         2. Copy the existing LBaaS "extension" and create a
> >         "new-lbaas" extension with new object names, then create a
> >         "new old lbaas" extension that has the "old API" but redirect
> >         to the "new API"
> > I also don't fully understand this, please explain.
> I need more clarification on this as well.  Sounds like you're saying to
> create a lbaas extension v2 with the new object names.  Then copy the
> existing lbaas extension and change it to redirect to the v2 extension.
> If that is the case, why create a "new old lbaas" and just change the
> "old lbaas" extension?
> >
> >
> >
> >         Doing 2, can allow "co-existence" of old code with old drivers
> >         until new code with new drivers can take its place.
> > New extension + new plugin, is that what you are suggesting? To me it
> > would be the cleanest and the most simple way to execute the
> > transition, but... i'm not sure it was a consensus on design session.
>
> I agree this would be the cleanest but I was under the impression this
> was not an accepted way to go.  I'd honestly prefer a v2 extension and
> v2 plugin.  This would require different names for the object model and
> db tables since you don't want the old api and new api sharing the same
> tables.  We can either append v2 to the names or rename them entirely.
> Sam suggested group for pool, healthcheck for healthmonitor, and node
> for member.  I'd prefer nodepool for pool myself.
>

nodepool isn't a bad name, eh. To throw this into the pot, too: How about
'backend' for the renamed pool (or does that imply too much)?


>
> Either way, I need to know if we can go with this route or not.  I've
> started on writing the code a bit but relationship conversations has
> stalled that some.  I think if we can go with this route it will make
> the code much more clear.
>
> Thanks,
> Brandon
>
>
Yep, knowing this is going to be key to where we need to put engineering
time into this, eh.

Stephen


-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140602/b0f2b666/attachment.html>