<div dir="ltr">Hi ya'll!<div><br></div><div>Comments inline:</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 1, 2014 at 1:09 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eugene and Sam,<br>
<div class=""><br>
On Sun, 2014-06-01 at 12:07 +0400, Eugene Nikanorov wrote:<br>
> Hi Sam,<br>
><br>
> Eugene, please comment on the migration process bellow.<br>
><br>
> I think that closing down the "status" handling should be done<br>
> in phase 1.<br>
> I don't mind. If you're talking about provisioning status then such<br>
> status (if we're still going to maintain it per each kind of object)<br>
> goes to various associations: loadbalancer-listener, or<br>
> loadbalancer-listener-pool, etc.<br>
> Not a big deal of course, it was just my initial intent to limit phase<br>
> #1 as much as possible.<br>
<br>
</div>I was hoping to limit it as well to keep it focused on just the<br>
refactoring portion. I didn't want the scope to include all new<br>
features and changes under the sun. It also makes reviewing much<br>
simpler.<br></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
><br>
><br>
> Missing to do so, will create tests and other depending<br>
> workflows that assume the "current" status field, which will<br>
> add a technology debt to this new code.<br>
> I'd say it would depend on the strategy options you're suggestion<br>
> below.<br>
> As far as bw compatibility is concerned (if it's concerned at all), we<br>
> have to support existing status field, so that would not be any<br>
> additional debt.<br>
><br>
><br>
> Migration and co-existence:<br>
> I think that it would be better to have the new object model<br>
> and API done in a way that does not "break" existing code, and<br>
> then switch the "old" api to redirect to the "new" api.<br>
> Basically this means creating another lbaas plugin, that expose<br>
> existing lbaas api extension.<br>
> I'm not sure how this can be done considering the difference between<br>
> new proposed api and existing api.<br>
><br>
> This might be done in one of the two ways bellow:<br>
> 1. Rename all objects in the "new" api so you have a clear<br>
> demarcation point. This might be sufficient.<br>
> I'm not sure how this could be done, can you explain?<br>
> I actually would consider changing the prefix to /v3/ to not to deal<br>
> with any renamings, that would require some minor refactoring on<br>
> extension framework side.<br>
</div>His suggestion in the BP was to rename pool, healthmonitor, and member<br>
to group, healthcheck, and node respectively. Since loadbalancer and<br>
listener are already new those don't have to be renamed. This way the<br>
old object models and db tables remain intact and the old API can still<br>
function as before.<br>
<div class="">><br>
> 2. Copy the existing LBaaS "extension" and create a<br>
> "new-lbaas" extension with new object names, then create a<br>
> "new old lbaas" extension that has the "old API" but redirect<br>
> to the "new API"<br>
> I also don't fully understand this, please explain.<br>
</div>I need more clarification on this as well. Sounds like you're saying to<br>
create a lbaas extension v2 with the new object names. Then copy the<br>
existing lbaas extension and change it to redirect to the v2 extension.<br>
If that is the case, why create a "new old lbaas" and just change the<br>
"old lbaas" extension?<br>
<div class="">><br>
><br>
><br>
> Doing 2, can allow "co-existence" of old code with old drivers<br>
> until new code with new drivers can take its place.<br>
> New extension + new plugin, is that what you are suggesting? To me it<br>
> would be the cleanest and the most simple way to execute the<br>
> transition, but... i'm not sure it was a consensus on design session.<br>
<br>
</div>I agree this would be the cleanest but I was under the impression this<br>
was not an accepted way to go. I'd honestly prefer a v2 extension and<br>
v2 plugin. This would require different names for the object model and<br>
db tables since you don't want the old api and new api sharing the same<br>
tables. We can either append v2 to the names or rename them entirely.<br>
Sam suggested group for pool, healthcheck for healthmonitor, and node<br>
for member. I'd prefer nodepool for pool myself.<br></blockquote><div><br></div><div>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)?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Either way, I need to know if we can go with this route or not. I've<br>
started on writing the code a bit but relationship conversations has<br>
stalled that some. I think if we can go with this route it will make<br>
the code much more clear.<br>
<br>
Thanks,<br>
Brandon<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote></div><div class="gmail_extra"><br></div>Yep, knowing this is going to be key to where we need to put engineering time into this, eh.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">Stephen<br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div></div>