Open Stack

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.

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.


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


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


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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140601/bfd6474d/attachment.html>