Open Stack

Hi Brandon Eugene and Everyone,

Eugene, please comment on the migration process bellow.

I think that closing down the "status" handling should be done in phase 1. 
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.

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

Doing 2, can allow "co-existence" of old code with old drivers until new code with new drivers can take its place.

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