[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