[openstack-dev] [Nova] New API requirements, review of GCE

Alexandre Levine alevine at cloudscaling.com
Tue Dec 10 16:13:57 UTC 2013


Yes, I understand it perfectly, Cristopher, and cannot agree more. It's 
just more work to reach this right now than use what's present. Still in 
my opinion even in a mid-run just till IceHouse release it might be less 
work overall.
I'm going to think it over.

Alex

10.12.2013 17:47, Christopher Yeoh ?????:
> 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?
>
> 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
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> 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/20131210/ae6216d0/attachment.html>


More information about the OpenStack-dev mailing list