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
<[email protected] <mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
