Open Stack

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.

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

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

>  
> 
> 
> Thanks,
> Eugene.
> 
> 
>         
>         Regards,
>                 -Sam.
>         
>         
>         
>         
>         -----Original Message-----
>         From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM]
>         Sent: Friday, May 30, 2014 6:38 PM
>         To: Samuel Bercovici
>         Subject: Your suggestions in the BP
>         
>         Hi Sam!
>         
>         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.
>         
>         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.
>         
>         Thanks,
>         Brandon
>         
>         
> 
>