<div dir="ltr">Hi Sam,<div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Eugene, please comment on the migration process bellow.<br>
<br>
I think that closing down the "status" handling should be done in phase 1.<br></blockquote><div>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. </div>
<div>Not a big deal of course, it was just my initial intent to limit phase #1 as much as possible.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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.<br></blockquote><div>I'd say it would depend on the strategy options you're suggestion below.</div>
<div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Migration and co-existence:<br>
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.<br></blockquote>
<div>Basically this means creating another lbaas plugin, that expose existing lbaas api extension.</div><div>I'm not sure how this can be done considering the difference between new proposed api and existing api.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 demarcation point. This might be sufficient.<br></blockquote><div>I'm not sure how this could be done, can you explain?</div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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"<br>
</blockquote><div>I also don't fully understand this, please explain.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Doing 2, can allow "co-existence" of old code with old drivers until new code with new drivers can take its place.<br></blockquote><div>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.</div>
<div> </div><div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
        -Sam.<br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Brandon Logan [mailto:<a href="mailto:brandon.logan@RACKSPACE.COM">brandon.logan@RACKSPACE.COM</a>]<br>
Sent: Friday, May 30, 2014 6:38 PM<br>
To: Samuel Bercovici<br>
Subject: Your suggestions in the BP<br>
<br>
Hi Sam!<br>
<br>
Thanks for the suggestions.  I don't think the different statuses should be addressed in the blueprint.  I think it would be better left to have its own focus in its own blueprint.  I feel the same way about the subnet_id.  I think if this blueprint focuses just on the object model change and the migration to it, it would be better.<br>

<br>
As for having a v2 version of all the table or entirely new tables.  Are you suggesting just keeping the old API going to the old object models and database tables?  Also, if say I renamed the pool object to nodepool (I prefer that over group), then are you also suggesting the new API will have a /nodepools resource along with the object model NodePool and database table nodepool?  I'm intrigued by this idea, but wasn't totally clear on what you were suggesting.<br>

<br>
Thanks,<br>
Brandon<br>
<br>
<br>
</blockquote></div><br></div></div></div>