04.12.2013 11:57, Christopher Yeoh ?????:
On Wed, Dec 4, 2013 at 5:22 PM, Alexandre Levine
<alev...@cloudscaling.com <mailto:alev...@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.
Agree.
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?
It is totally possible to sit the GCE API on top of the Nova, Neutron,
Cinder and other REST APIs. In fact It is already on top of other REST
APIs except for Nova services which we'd implemented as it's done in EC2
for uniformity's sake.
Chris
Best regards,
Alex Levine
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
