Hi ya'll! Comments inline:
On Sun, Jun 1, 2014 at 1:09 PM, Brandon Logan <[email protected]> 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
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
