Open Stack

On Tue, Dec 10, 2013 at 11:36 PM, Alexandre Levine <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?

Chris



> Alex
>
> 06.12.2013 22:43, Russell Bryant пишет:
>
>  On 12/02/2013 02:06 PM, Eric Windisch wrote:
>>
>>> What more is needed from the blueprint or the patch authors to proceed?
>>>
>> I finally got back to looking at this.  Here is how I would like to
>> proceed with GCE.
>>
>> 1) Stackforge
>>
>> It seems like this code is pretty self contained.  I'd like to see it
>> imported into a stackforge repository.  Then, I'd like to see jenkins
>> jobs showing that both the unit tests and the functional tests written
>> for this are passing.  It will also help keep the code up to date with
>> Nova while it's not in the main tree.
>>
>> 2) Support from nova-core
>>
>> Taking on a new API in Nova has a significant ongoing maintenance
>> impact.  I'm assuming that the submitters are willing to help maintain
>> the code.  We also need commitment from some subset of nova-core to
>> review this code.
>>
>> So, what do folks from nova-core think?  Are you on board with
>> maintaining this API?
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131211/b82b0ba1/attachment.html>