-----Original Message-----
From: Samuel Bercovici
Sent: Sunday, June 01, 2014 10:19 AM
To: 'Brandon Logan'; OpenStack Development Mailing List (not for usage
questions); Eugene Nikanorov ([email protected])
Subject: RE: Your suggestions in the BP
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:[email protected]]
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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
