Thanks Ignasi.
Yes, you are right. I don't need any changes to start using.
I am able to run the live tests following below instructions [1], [2].
I feel some steps are not clear(for a new jclouds/gce user), and would like
to post my steps in a bit more detailed manner(may be in my blog).
I will start looking at how to use in a separate example project(following
your suggestion [3]), and try to post them as well.
In case if anybody is interested on result of my live tests:
Single OAuth live test passed:
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.573 sec
Some GCE live tests failed:
Tests run: 86, Failures: 2, Errors: 0, Skipped: 11
Looks to me failures are due to network operations quota exceeded.
statusCode=403, message=FORBIDDEN, headers={}}, operationType=insert,
errors=[Error{code=QUOTA_EXCEEDED, message=Quota 'NETWORKS' exceeded.
Limit: 5.0}]}
[1]
https://github.com/jclouds/jclouds-labs-google/tree/master/google-compute-engine
[2] https://github.com/jclouds/jclouds-labs-google/tree/master/oauth
[3] http://www.mail-archive.com/[email protected]/msg04369.html
On Mon, Mar 10, 2014 at 1:36 AM, Ignasi Barrera <[email protected]>wrote:
> Hi Suriya,
>
> Despite being in a different "labs" repository, the GCE provider is
> also released as part of the regular release process. You'll find the
> release artifacts in Maven Central [1], so you download or include
> them as a dependency where needed. Moving the provider to the main
> repository should not be a blocker for downstream projects, as long as
> they can use the released artifacts.
>
> Creating the provider metadata class should be ideal, but I'm not sure
> if it would be a must. A "provider" in jclouds is just an "api",
> exposed in a concrete location, with a set of defaults (check this [2]
> core concept definition page). Many providers have common APIs (think
> about OpenStack providers). While the API they expose is the same
> (nova, swift, etc), the endpoints where they expose the api and some
> defaults change. That is what the provider metadata describes.
>
> Even though if there is no provider metadata describing a "concrete
> deployment of the api", you can still instanciate the provider, using
> the ContextBuilder normally.
> You can use "google-compute-engine" as the provider id, and use the
> default endpoint, defined by the GoogleComputeEngineApiMetadata [3].
> If you have the provider dependency in your classpath, jclouds will
> find it and pick it up.
>
>
>
> So, taking into account these things (if I am not missing something)
> you should be already able to use the GCE provider without having to
> wait for those changes in the jclouds side.
>
>
>
> HTH!
>
>
> Ignasi
>
>
> [1]
> http://search.maven.org/#artifactdetails%7Corg.apache.jclouds.labs%7Cgoogle-compute-engine%7C1.7.1%7Cjar
> [2] http://wiki.apache.org/jclouds/Core%20Concepts
> [3]
> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/GoogleComputeEngineApiMetadata.java#L78-L85
>
> On 10 March 2014 09:18, Sathyasuriya Priya <[email protected]> wrote:
> > Dear Jclouds developers,
> >
> > I am Suriyapriya Veluchamy, currently an MS CS student at NPU, Fremont,
> CA,
> > USA.
> > I am interested in the following GSOC project in Stratos.
> > https://issues.apache.org/jira/browse/STRATOS-480
> >
> > I have some queries on the GCE support in jclouds, since this is needed
> for
> > Stratos to integrate with GCE.
> > https://github.com/jclouds/jclouds-labs-google
> >
> > I looked at a relevant email thread as well.
> > http://www.mail-archive.com/[email protected]/msg04369.html
> >
> > I understand the following JIRA issue is for moving the separate GCE
> > project to the core project.
> > https://issues.apache.org/jira/browse/JCLOUDS-172
> >
> > I would like to understand the complexity of this work, based on which I
> > would decide whether it could be part of my gsoc work. I have come up
> with
> > list of todo items, based on my analysis. Pls correct me or add other
> items
> > needed as well.
> >
> > 1. Create GCEProviderMetadata extending BaseProviderMetadata (similar to
> > AWSEC2ProviderMetadata) - this is needed for
> > ContextBuilder.newBuilder(provider) to pick up GCE ?
> > 2. Move all the files (oauth, google-compute-engine) to
> > jclouds-providers-project.
> > 3. Hopefully, jclouds should pick up GCE as provider. Fix any issues that
> > come up.
> > 4. Andrew Bayer's criticisms of OAuth code - I couldn't find the relevant
> > discussion/email related to this. Any idea if this is a critical piece
> and
> > how much effort is needed to fix it.
> >
> > I am assuming other jclouds components are provider agnostic and
> shouldn't
> > break. Do you aware of any other code changes needed in other components.
> >
> > Also, I came across the GCE API java library from google. Any idea why we
> > don't use it directly (instead rely on REST apis). May be for OAuth
> support
> > alone we can make use of this ?
> > https://developers.google.com/compute/docs/api/api-lib/java
> >
> > I was able to build jclouds-labs-google and run unittests successfully.
> > I will try to work on an example to make use of this project and will
> > update.
> >
> > Thanks
> > Suriya
>
