Does nova actually have add-ons infrastructure in which our GCE API can
fit? I see the plugins with xen-server only and have found this link:
http://docs.openstack.org/developer/nova/api/nova.openstack.common.plugin.plugin.html.
Is it the thing? I'm trying to understand what you meant by this: "If it
doesn't go into Nova, this would be a good way to manage it as an add-on".
Also if we do it a separate service does it remove necessity for support
commitment from the nova core team? And if it does who would have to
commit instead?
Sorry if I ask some obvious questions.
Alex
10.12.2013 18:56, Russell Bryant пишет:
On 12/10/2013 08:47 AM, Christopher Yeoh wrote:
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?
#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.
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
