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.

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.

Best regards,
   Alex Levine

04.12.2013 0:15, Eric Windisch ?????:
> One other issue with the proposed GCE changes is that it uses the custom
> wsgi which we are trying to phase out eventually. Should we be suggesting
> that new APIs use Pecan/WSME?

Nova isn't using Pecan/WSME for any of its API services. Is Nova truly
going in this direction? I'd think that consistency with Nova would
take precedence over perceived overall OpenStack momentum. The GCE
code could be updated along with the rest of Nova.  However, if the
community is committed to migrating Nova over to Pecan/WSME across the
board, it shouldn't be too problematic to update the GCE code prior to
submission.

Does anyone else care to comment or discuss using Pecan/WSME? Alex
Levine? Doug Hellman? Russell?

--
Regards,
Eric Windisch


_______________________________________________
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

Reply via email to