Open Stack

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
>> <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?
> #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.
>