I can see two sides to this:
1. it is a distraction:
GCE especially an inexperienced api, when we know all new apis
change (v1beta12 anyone?) While fun, it implies coding to another spec
outside our control (ala) EC2, and implies setting up an OAUTH 2
layer. esp as the current EC2 api isn't
I think that google (specially google app engine) has a big developer base
that will try/use GCE in the short term.
A few 3rd party tools already announced compatibility with GCE.
It could be another crowd that will use Cloudstack.
David
On Fri, Jun 29, 2012 at 8:15 PM, Chiradeep Vittal <
chirad
If I was new to CloudStack / IAAS cloud, it would be a learning experience
to map concepts from one cloud implementation to another. See if the
abstractions in CloudStack are abstract enough or perhaps they need more
refinement.
It could attract more folks (GOOG fans) to the CloudStack community.
On Fri, Jun 29, 2012 at 8:01 PM, George Reese
wrote:
> One has an AWS API to take advantage of the AWS ecosystem. No Google
> ecosystem exists.
>
I agree.
When/If GCE gets market traction, and the follow on ecosystem tools
perhaps it will be time to do it. Aside from that, what is the
benefit? (
One has an AWS API to take advantage of the AWS ecosystem. No Google
ecosystem exists.
Sent from my iPhone
On Jun 29, 2012, at 18:59, Chiradeep Vittal wrote:
> Along the lines of the AWS API front-end to CloudStack, would anybody be
> interested in developing the GCE front-end? The GCE API [1]
Along the lines of the AWS API front-end to CloudStack, would anybody be
interested in developing the GCE front-end? The GCE API [1] is quite elementary
— the most complex piece would be adding an OAuth2 server and integrate that
with CloudStack's API key management.
GCE maps to basic zone: the
