Open Stack

On Wed, Dec 4, 2013 at 5:22 PM, Alexandre Levine
<alevine at cloudscaling.com>wrote:

>  It is not a problem to update the code in given direction when the
> decision is made. As I understood right now it's not about the code -
> that's why I'd canceled the code review until the blueprint is accepted -
> it's more about architecture and procedures such as which tests should be
> obligatory and alike.
>
> My vision of architecture when we'd started the project was:
> Yes, eventually GCE API as well as EC2 should be a separate service
> because of the following reasons:
> 1. It covers wider functionality than compute - in fact it covers almost
> the whole cloud. That's why both EC2 and GCE have to go to Neutron, Cinder
> and other services out of the nova boundaries to perform tasks not related
> to compute at all.
> 2. Nova is quite big already and has lots of services. It'll be great to
> disintegrate it a little bit for simplicity, loose coupling and such other
> reasons.
>
> But:
> As long as EC2 is in the nova other alike APIs might stay there as well.
> And it is rather a different task to separate them from it.
>

It does add a small amount of overhead to making changes to internal Nova
apis as in addition to making the appropriate changes to the native Nova
API and EC2, patches will also have to modify the GCE API as well.


>
> The thing is - we can make GCE API a separate service but we need to be
> told about that. Some decisions should be made so that we could react or we
> won't have time and might miss even Icehouse.
>
>
Apologies if I've missed an answer to this question before, but would it be
possible to sit the GCE API on top of the Nova REST API which has much
higher guarantees of stability compared to the internal Nova APIs?

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131204/bfb9abed/attachment.html>