Open Stack

On 12/10/2013 08:47 AM, Christopher Yeoh wrote:
> On Tue, Dec 10, 2013 at 11:36 PM, Alexandre Levine
> <alevine at cloudscaling.com <mailto:alevine at cloudscaling.com>> wrote:
> 
>     Russell,
> 
>     I'm a little confused about importing it into stackforge repository.
>     Please clarify it for me.
>     Right now our code is a part of nova itself, adding lots of files
>     and changing several of existing, namely: service.py, cmd/api.py,
>     setup.cfg, api-paste.ini and nova.conf.sample. This is only the
>     core. Also our functional code for some marginal GCE API
>     functionality has to use database (to store naming translation).
>     So for creating the stackforge repository we have 3 different
>     options with different costs in terms of additional labor:
>     1. Create the copy of nova and add GCE as a part of it. - I don't
>     fill it to be a customary way for such additions but it'll be the
>     least costly for us.
>     2. Separate our code from nova leaving it its part still. Stackforge
>     repository will contain only GCE code. It'd be installed after the
>     nova is installed, create another nova service, change api-paste.ini
>     and nova.conf, create tables in nova DB (or create its own DB, I'm
>     not sure here). This will require some changes for the present code
>     but not many though.
>     3. Completely separate GCE and make it a standalone service using
>     nova via REST. The most costly options for us now. Still doable as well.
> 
> 
> In the long run I suspect that option 3 will probably be the least work
> for everyone. Why be dependent on changes to Nova's internal APIs unless
> you really have to when you have the alternative of being dependent on a
> much more stable REST API?

#3 is preferable by far, IMO.

#2 is roughly what I was suggesting.  If it doesn't go into Nova, this
would be a good way to manage it as an add-on.  If it does go into Nova,
it would be a good way to stage such a big addition, since we'll be able
to see CI running the tests against it.  That's beneficial for the code
even if it doesn't go into Nova.

I'm still waiting to see what kind of support there is for this.  We
really need clear support for it being in the tree before accepting the
ongoing maintenance and review burden.

-- 
Russell Bryant