You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jclouds.apache.org by Paul <ar...@gmail.com> on 2013/11/05 00:10:34 UTC
Support for VMware vCloud Director
Hi,
At the risk of looking like an annoying noob, I thought I would re-post this. This began as private correspondence with Andrew Phillips who has already posted it. But I thought I would clearly attach my name to it.
My goal is to use jclouds (or Whirr) to create a bunch of VMware VMs each "automatically" configured with Centos and MongoDB.
I read somewhere on the Web that if jclouds supports a particular provider, then Whirr does, too. But, in reading http://jclouds.incubator.apache.org/documentation/userguide/vmware-vCloud, I got confused. My installation doesn't have any of the listed providers, e.g., Terremark or Bluelock. We just run VMware's VCD - as is - so to speak.
I would be most grateful for some guidance in how to go about using jclouds to talk "directly" to VMware's VCD.
Thank you for your help.
-Paul
Re: Support for VMware vCloud Director
Posted by Ignasi <ig...@gmail.com>.
Hi Paul,
jclouds-all is just an aggregator pom [1] that adds the dependencies
to all providers in the *main* repo, but does *not* include the
providers in labs.
To use those providers you need to manually add the dependencies for
the providers you are going to use, vcloud-director [2] in your case.
HTH
Ignasi
[1] https://github.com/jclouds/jclouds/tree/master/all
[2] https://github.com/jclouds/jclouds-labs/blob/master/vcloud-director/pom.xml
On 5 November 2013 16:07, Paul Bell <ar...@gmail.com> wrote:
> Hi again,
>
> I should have mentioned that I am using the 1.6.1 incubating release. Well,
> the project POM contains:
>
> <dependency>
> <groupId>org.apache.jclouds</groupId>
> <artifactId>jclouds-all</artifactId>
> <version>1.6.1-incubating</version>
> </dependency>
> <dependency>
> <groupId>org.apache.jclouds.driver</groupId>
> <artifactId>jclouds-sshj</artifactId>
> <version>1.6.1-incubating</version>
> </dependency>
>
> And I do see among the Maven dependencies a bunch of 1.6.1 jar files
> including jclouds-all-1.6.1-incubating.jar.
>
> Thanks again.
>
> -Paul
>
>
> On Mon, Nov 4, 2013 at 7:45 PM, Andrew Phillips <an...@apache.org> wrote:
>>>
>>> I would be most grateful for some guidance in how to go about using
>>> jclouds to talk "directly" to VMware's VCD.
>>
>>
>> You should be able to instantiate a context using the "plain"
>> 'vcloud-director' API, setting (at minimum) the "endpoint" property for your
>> target installation:
>>
>> Properties overrides = new Properties();
>> overrides.setProperty(..., ...);
>> overrides.setProperty(..., ...);
>>
>> ComputeServiceContext context =
>> ContextBuilder.newBuilder("vcloud-director")
>> .endpoint("https://your-vloud-ip-or-host/api")
>> .credentials("user@org", "password")
>> //.overrides(overrides) - only if needed
>> .buildView(ComputeServiceContext.class);
>>
>> computeService = context.getComputeService();
>> // do something with the compute service
>>
>> You can see some of the properties you can specific via the overrides in
>> the API metadata [1]. You'll notice that providers using the vCloud Director
>> API, such as Carrenza, effectively do just that in their provider metadata
>> [2].
>>
>> What I don't know, however, is whether or how Whirr allows you to specify
>> a context such as this one. One of the Whirr-savvy members of the list will
>> hopefully be able to help out here!
>>
>> ap
>>
>> [1]
>> https://github.com/jclouds/jclouds-labs/blob/master/vcloud-director/src/main/java/org/jclouds/vcloud/director/v1_5/VCloudDirectorApiMetadata.java#L59
>> [2]
>> https://github.com/jclouds/jclouds-labs/blob/master/carrenza-vcloud-director/src/main/java/org/jclouds/carrenza/vcloud/director/CarrenzaVCloudDirectorProviderMetadata.java#L69
>
>
Re: Support for VMware vCloud Director
Posted by Paul Bell <ar...@gmail.com>.
Hi again,
I should have mentioned that I am using the 1.6.1 incubating release. Well,
the project POM contains:
<dependency>
<groupId>org.apache.jclouds</groupId>
<artifactId>jclouds-all</artifactId>
<version>1.6.1-incubating</version>
</dependency>
<dependency>
<groupId>org.apache.jclouds.driver</groupId>
<artifactId>jclouds-sshj</artifactId>
<version>1.6.1-incubating</version>
</dependency>
And I do see among the Maven dependencies a bunch of 1.6.1 jar files
including jclouds-all-1.6.1-incubating.jar.
Thanks again.
-Paul
On Mon, Nov 4, 2013 at 7:45 PM, Andrew Phillips <an...@apache.org> wrote:
> I would be most grateful for some guidance in how to go about using
>> jclouds to talk "directly" to VMware's VCD.
>>
>
> You should be able to instantiate a context using the "plain"
> 'vcloud-director' API, setting (at minimum) the "endpoint" property for
> your target installation:
>
> Properties overrides = new Properties();
> overrides.setProperty(..., ...);
> overrides.setProperty(..., ...);
>
> ComputeServiceContext context = ContextBuilder.newBuilder("
> vcloud-director")
> .endpoint("https://your-vloud-ip-or-host/api")
> .credentials("user@org", "password")
> //.overrides(overrides) - only if needed
> .buildView(ComputeServiceContext.class);
>
> computeService = context.getComputeService();
> // do something with the compute service
>
> You can see some of the properties you can specific via the overrides in
> the API metadata [1]. You'll notice that providers using the vCloud
> Director API, such as Carrenza, effectively do just that in their provider
> metadata [2].
>
> What I don't know, however, is whether or how Whirr allows you to specify
> a context such as this one. One of the Whirr-savvy members of the list will
> hopefully be able to help out here!
>
> ap
>
> [1] https://github.com/jclouds/jclouds-labs/blob/master/
> vcloud-director/src/main/java/org/jclouds/vcloud/director/v1_5/
> VCloudDirectorApiMetadata.java#L59
> [2] https://github.com/jclouds/jclouds-labs/blob/master/
> carrenza-vcloud-director/src/main/java/org/jclouds/
> carrenza/vcloud/director/CarrenzaVCloudDirectorProviderMetadata.java#L69
>
Re: Support for VMware vCloud Director
Posted by Bk Lau <bk...@gmail.com>.
Ignasi:
Absolutely! :)
On Fri, Nov 8, 2013 at 11:45 AM, Ignasi <ig...@gmail.com> wrote:
> Perhaps something similar to what is implemented in Abiquo could be useful
> if implemented.
>
> Abiquo is a HATEOAS api that makes a lot use of links to express relations
> between entities. To make things easier and hide all link manipulation
> logic (it is not black magic but can take a bit to get used to it), the
> domain objects have behavior and do that operations and provide a more user
> friendly and high level interface.
> El 08/11/2013 17:40, "Bk Lau" <bk...@gmail.com> escribió:
>
> As a feedback:
>>
>> The current JCloud VCloudDirectorApi is very similar to VMWare's vCloud
>> API SDK.
>> Both still mirror the REST HATEOUS links transversal at the
>> payload/response substrate level.
>> From end user point of view, it would help not to think about the "links"
>> because they are just
>> marshalling/unmarshalling mechanism in REST fashion.
>> I think a higher level "vCloudClient" on top on current
>> VCloudDirectorApi would make it easier to use.
>>
>>
>> On Wed, Nov 6, 2013 at 2:19 PM, Paul Bell <ar...@gmail.com> wrote:
>>
>>> Hi again,
>>>
>>> Making some progress now.
>>>
>>> The "not wrappable as org.jclouds.compute.ComputeServiceContext" error
>>> that I previously mentioned continues to occur. About this I discovered the
>>> following:
>>>
>>>
>>> http://mail-archives.apache.org/mod_mbox/jclouds-user/201309.mbox/%3c5228A784.3090606@gmail.com%3e
>>>
>>> I think this is saying that the ComputeService implementation for VCD is
>>> not yet finished. What does this mean? For example, per Andrew's
>>> observation re using a provider-specific approach, am I presently
>>> constrained to just such an approach? If so, then won't my code - at least
>>> for the time being - be limited to a single provider (VCD)?
>>>
>>> The comment in the mail archives indicates that, because the VCD domain
>>> model is implemented, it's now possible to drive the underlying VCD REST
>>> API via Java. But this capability was already present in the VMware Java
>>> API for VCD.
>>>
>>> Another question: if I am presently constrained to provider-specific
>>> API, then will the first link that Andrew posted (MainApp.java) help me?
>>> That is, it seems to deal in the nice jclouds abstractions, like "portable
>>> views." But, unless I am sorely mistaken (always possible!), I don't
>>> presently have access to these abstractions for VCD.
>>>
>>> That said, I will quite happily study that code to learn more of the
>>> jclouds idiom. But my immediate need is the ability to:
>>>
>>> a. create one or more vApps, each consisting of one or more VMs.
>>> b. deploy thereon an OVA/OVF
>>> c. configure application specific stuff on these VMs
>>> d. start them up
>>>
>>> Again, thank you for your help & light.
>>>
>>> Cordially,
>>>
>>> Paul
>>>
>>> On Wed, Nov 6, 2013 at 1:04 PM, Paul Bell <ar...@gmail.com> wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> Thank you for this guidance.
>>>>
>>>> I will get on it!
>>>>
>>>> -Paul
>>>>
>>>> On Wed, Nov 6, 2013 at 12:36 PM, Andrew Phillips <an...@apache.org>wrote:
>>>>
>>>>> Hi Paul
>>>>>
>>>>> First of all, please use 1.6.2-incubating for all the dependencies, to
>>>>> avoid any incompatibilities arising from that.
>>>>>
>>>>> As regards sample code, we're probably best off looking at the
>>>>> compute-basics example [1] and the BaseVCloudDirectorApiLiveTest [2].
>>>>>
>>>>> If we want to work directly with the vendor-specific vCloud API,
>>>>> rather than one of jclouds' portable views such as the
>>>>> ComputeServiceContext, we can also get hold of the API directly, by the way:
>>>>>
>>>>> VCloudDirectorApi vcdApi =
>>>>>
>>>>> ContextBuilder.newBuilder("vcloud-director")
>>>>> .endpoint("https://dpvcloud.company.com")
>>>>> .credentials("pbell@MyOrg", "mypassword")
>>>>> .buildApi(VCloudDirectorApi.class);
>>>>>
>>>>> See the ContextBuilder Javadoc [3] for more details.
>>>>>
>>>>> ap
>>>>>
>>>>> [1] https://github.com/jclouds/jclouds-examples/blob/master/
>>>>> compute-basics/src/main/java/org/jclouds/examples/compute/
>>>>> basics/MainApp.java
>>>>> [2] https://github.com/jclouds/jclouds-labs/blob/master/
>>>>> vcloud-director/src/test/java/org/jclouds/vcloud/director/
>>>>> v1_5/internal/BaseVCloudDirectorApiLiveTest.java
>>>>> [3] http://javadocs.jclouds.cloudbees.net/org/jclouds/
>>>>> ContextBuilder.html
>>>>>
>>>>
>>>>
>>>
>>
Re: Support for VMware vCloud Director
Posted by Ignasi <ig...@gmail.com>.
Perhaps something similar to what is implemented in Abiquo could be useful
if implemented.
Abiquo is a HATEOAS api that makes a lot use of links to express relations
between entities. To make things easier and hide all link manipulation
logic (it is not black magic but can take a bit to get used to it), the
domain objects have behavior and do that operations and provide a more user
friendly and high level interface.
El 08/11/2013 17:40, "Bk Lau" <bk...@gmail.com> escribió:
> As a feedback:
>
> The current JCloud VCloudDirectorApi is very similar to VMWare's vCloud
> API SDK.
> Both still mirror the REST HATEOUS links transversal at the
> payload/response substrate level.
> From end user point of view, it would help not to think about the "links"
> because they are just
> marshalling/unmarshalling mechanism in REST fashion.
> I think a higher level "vCloudClient" on top on current VCloudDirectorApi
> would make it easier to use.
>
>
> On Wed, Nov 6, 2013 at 2:19 PM, Paul Bell <ar...@gmail.com> wrote:
>
>> Hi again,
>>
>> Making some progress now.
>>
>> The "not wrappable as org.jclouds.compute.ComputeServiceContext" error
>> that I previously mentioned continues to occur. About this I discovered the
>> following:
>>
>>
>> http://mail-archives.apache.org/mod_mbox/jclouds-user/201309.mbox/%3c5228A784.3090606@gmail.com%3e
>>
>> I think this is saying that the ComputeService implementation for VCD is
>> not yet finished. What does this mean? For example, per Andrew's
>> observation re using a provider-specific approach, am I presently
>> constrained to just such an approach? If so, then won't my code - at least
>> for the time being - be limited to a single provider (VCD)?
>>
>> The comment in the mail archives indicates that, because the VCD domain
>> model is implemented, it's now possible to drive the underlying VCD REST
>> API via Java. But this capability was already present in the VMware Java
>> API for VCD.
>>
>> Another question: if I am presently constrained to provider-specific API,
>> then will the first link that Andrew posted (MainApp.java) help me? That
>> is, it seems to deal in the nice jclouds abstractions, like "portable
>> views." But, unless I am sorely mistaken (always possible!), I don't
>> presently have access to these abstractions for VCD.
>>
>> That said, I will quite happily study that code to learn more of the
>> jclouds idiom. But my immediate need is the ability to:
>>
>> a. create one or more vApps, each consisting of one or more VMs.
>> b. deploy thereon an OVA/OVF
>> c. configure application specific stuff on these VMs
>> d. start them up
>>
>> Again, thank you for your help & light.
>>
>> Cordially,
>>
>> Paul
>>
>> On Wed, Nov 6, 2013 at 1:04 PM, Paul Bell <ar...@gmail.com> wrote:
>>
>>> Hi Andrew,
>>>
>>> Thank you for this guidance.
>>>
>>> I will get on it!
>>>
>>> -Paul
>>>
>>> On Wed, Nov 6, 2013 at 12:36 PM, Andrew Phillips <an...@apache.org>wrote:
>>>
>>>> Hi Paul
>>>>
>>>> First of all, please use 1.6.2-incubating for all the dependencies, to
>>>> avoid any incompatibilities arising from that.
>>>>
>>>> As regards sample code, we're probably best off looking at the
>>>> compute-basics example [1] and the BaseVCloudDirectorApiLiveTest [2].
>>>>
>>>> If we want to work directly with the vendor-specific vCloud API, rather
>>>> than one of jclouds' portable views such as the ComputeServiceContext, we
>>>> can also get hold of the API directly, by the way:
>>>>
>>>> VCloudDirectorApi vcdApi =
>>>>
>>>> ContextBuilder.newBuilder("vcloud-director")
>>>> .endpoint("https://dpvcloud.company.com")
>>>> .credentials("pbell@MyOrg", "mypassword")
>>>> .buildApi(VCloudDirectorApi.class);
>>>>
>>>> See the ContextBuilder Javadoc [3] for more details.
>>>>
>>>> ap
>>>>
>>>> [1] https://github.com/jclouds/jclouds-examples/blob/master/
>>>> compute-basics/src/main/java/org/jclouds/examples/compute/
>>>> basics/MainApp.java
>>>> [2] https://github.com/jclouds/jclouds-labs/blob/master/
>>>> vcloud-director/src/test/java/org/jclouds/vcloud/director/
>>>> v1_5/internal/BaseVCloudDirectorApiLiveTest.java
>>>> [3] http://javadocs.jclouds.cloudbees.net/org/jclouds/
>>>> ContextBuilder.html
>>>>
>>>
>>>
>>
>
Re: Support for VMware vCloud Director
Posted by Bk Lau <bk...@gmail.com>.
As a feedback:
The current JCloud VCloudDirectorApi is very similar to VMWare's vCloud API
SDK.
Both still mirror the REST HATEOUS links transversal at the
payload/response substrate level.
>From end user point of view, it would help not to think about the "links"
because they are just
marshalling/unmarshalling mechanism in REST fashion.
I think a higher level "vCloudClient" on top on current VCloudDirectorApi
would make it easier to use.
On Wed, Nov 6, 2013 at 2:19 PM, Paul Bell <ar...@gmail.com> wrote:
> Hi again,
>
> Making some progress now.
>
> The "not wrappable as org.jclouds.compute.ComputeServiceContext" error
> that I previously mentioned continues to occur. About this I discovered the
> following:
>
>
> http://mail-archives.apache.org/mod_mbox/jclouds-user/201309.mbox/%3c5228A784.3090606@gmail.com%3e
>
> I think this is saying that the ComputeService implementation for VCD is
> not yet finished. What does this mean? For example, per Andrew's
> observation re using a provider-specific approach, am I presently
> constrained to just such an approach? If so, then won't my code - at least
> for the time being - be limited to a single provider (VCD)?
>
> The comment in the mail archives indicates that, because the VCD domain
> model is implemented, it's now possible to drive the underlying VCD REST
> API via Java. But this capability was already present in the VMware Java
> API for VCD.
>
> Another question: if I am presently constrained to provider-specific API,
> then will the first link that Andrew posted (MainApp.java) help me? That
> is, it seems to deal in the nice jclouds abstractions, like "portable
> views." But, unless I am sorely mistaken (always possible!), I don't
> presently have access to these abstractions for VCD.
>
> That said, I will quite happily study that code to learn more of the
> jclouds idiom. But my immediate need is the ability to:
>
> a. create one or more vApps, each consisting of one or more VMs.
> b. deploy thereon an OVA/OVF
> c. configure application specific stuff on these VMs
> d. start them up
>
> Again, thank you for your help & light.
>
> Cordially,
>
> Paul
>
> On Wed, Nov 6, 2013 at 1:04 PM, Paul Bell <ar...@gmail.com> wrote:
>
>> Hi Andrew,
>>
>> Thank you for this guidance.
>>
>> I will get on it!
>>
>> -Paul
>>
>> On Wed, Nov 6, 2013 at 12:36 PM, Andrew Phillips <an...@apache.org>wrote:
>>
>>> Hi Paul
>>>
>>> First of all, please use 1.6.2-incubating for all the dependencies, to
>>> avoid any incompatibilities arising from that.
>>>
>>> As regards sample code, we're probably best off looking at the
>>> compute-basics example [1] and the BaseVCloudDirectorApiLiveTest [2].
>>>
>>> If we want to work directly with the vendor-specific vCloud API, rather
>>> than one of jclouds' portable views such as the ComputeServiceContext, we
>>> can also get hold of the API directly, by the way:
>>>
>>> VCloudDirectorApi vcdApi =
>>>
>>> ContextBuilder.newBuilder("vcloud-director")
>>> .endpoint("https://dpvcloud.company.com")
>>> .credentials("pbell@MyOrg", "mypassword")
>>> .buildApi(VCloudDirectorApi.class);
>>>
>>> See the ContextBuilder Javadoc [3] for more details.
>>>
>>> ap
>>>
>>> [1] https://github.com/jclouds/jclouds-examples/blob/master/
>>> compute-basics/src/main/java/org/jclouds/examples/compute/
>>> basics/MainApp.java
>>> [2] https://github.com/jclouds/jclouds-labs/blob/master/
>>> vcloud-director/src/test/java/org/jclouds/vcloud/director/v1_5/internal/
>>> BaseVCloudDirectorApiLiveTest.java
>>> [3] http://javadocs.jclouds.cloudbees.net/org/jclouds/
>>> ContextBuilder.html
>>>
>>
>>
>
Re: Support for VMware vCloud Director
Posted by Andrew Phillips <an...@apache.org>.
Quoting Ignasi <ig...@gmail.com>:
> This error is also due to SSL. In addition to the property Andrew
> suggested, set the following one to "true" too:
> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/Constants.java#L182-L188
Thanks, Ignasi!
@Paul: the error message could indeed be more helpful, by showing the
hostname in the certificate (as well as the one that's expected)...
ap
Re: Support for VMware vCloud Director
Posted by Paul Bell <ar...@gmail.com>.
Excellent; thank you.
-Paul
On Thu, Nov 7, 2013 at 10:58 AM, Ignasi <ig...@gmail.com> wrote:
> This error is also due to SSL. In addition to the property Andrew
> suggested, set the following one to "true" too:
>
> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/Constants.java#L182-L188
>
> On 7 November 2013 16:45, Paul Bell <ar...@gmail.com> wrote:
> > Hi Andrew,
> >
> > I made the change you suggested (thank you) and the symptom changed. I am
> > now getting this exception:
> >
> > Exception in thread "main" org.jclouds.http.HttpResponseException:
> > org.jclouds.http.HttpResponseException: HTTPS hostname wrong: should be
> > <dpvcloud.mycompany.com> connecting to POST
> > https://dpvcloud.mycompany.com/sessions HTTP/1.1 connecting to GET
> > https://dpvcloud.mycompany.com/org/ HTTP/1.1
> > at
> >
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:162)
> > at
> >
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.invoke(InvokeSyncToAsyncHttpMethod.java:131)
> > at
> >
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:97)
> > at
> >
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:58)
> > at
> >
> org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
> > at
> >
> com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:70)
> > at $Proxy56.list(Unknown Source)
> > at test.VcdTest.main(VcdTest.java:62)
> >
> > Line 62 in my VcdTest.java is a call to orgApi.list().
> >
> > I'm not sure how to interpret these phenomena, but I'd hazard the guess
> > that, prior to actually presenting the GET for "org", jclouds needs to
> > establish a session with VCD. Hence the POST for "sessions". I've done
> this
> > programmatically via the actual VCD REST API (as opposed to the Java
> SDK).
> > In response to this request, VCD is supposed to return an authorization
> > token that can then be used in the x-dpvcloud-authorization header.
> >
> > In any event, it's hard to see why I'm getting a "hostname wrong" error
> > because the actual and "should be" hostnames are identical.
> >
> > Cordially,
> >
> > Paul
> >
> > On Wed, Nov 6, 2013 at 5:52 PM, Andrew Phillips <an...@apache.org>
> wrote:
> >>
> >> You might want to try the following (haven't tested it, I have to say):
> >>
> >>
> >> Properties overrides = new Properties();
> >> overrides.setProperty(Constants.PROPERTY_TRUST_ALL_CERTS, "true");
> >>
> >> and then add this in to the context creation via
> >> ".overrides(overrides).buildApi(...)"
> >>
> >> Hope this helps!
> >>
> >> ap
> >
> >
>
Re: Support for VMware vCloud Director
Posted by Ignasi <ig...@gmail.com>.
This error is also due to SSL. In addition to the property Andrew
suggested, set the following one to "true" too:
https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/Constants.java#L182-L188
On 7 November 2013 16:45, Paul Bell <ar...@gmail.com> wrote:
> Hi Andrew,
>
> I made the change you suggested (thank you) and the symptom changed. I am
> now getting this exception:
>
> Exception in thread "main" org.jclouds.http.HttpResponseException:
> org.jclouds.http.HttpResponseException: HTTPS hostname wrong: should be
> <dpvcloud.mycompany.com> connecting to POST
> https://dpvcloud.mycompany.com/sessions HTTP/1.1 connecting to GET
> https://dpvcloud.mycompany.com/org/ HTTP/1.1
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:162)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.invoke(InvokeSyncToAsyncHttpMethod.java:131)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:97)
> at
> org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:58)
> at
> org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
> at
> com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:70)
> at $Proxy56.list(Unknown Source)
> at test.VcdTest.main(VcdTest.java:62)
>
> Line 62 in my VcdTest.java is a call to orgApi.list().
>
> I'm not sure how to interpret these phenomena, but I'd hazard the guess
> that, prior to actually presenting the GET for "org", jclouds needs to
> establish a session with VCD. Hence the POST for "sessions". I've done this
> programmatically via the actual VCD REST API (as opposed to the Java SDK).
> In response to this request, VCD is supposed to return an authorization
> token that can then be used in the x-dpvcloud-authorization header.
>
> In any event, it's hard to see why I'm getting a "hostname wrong" error
> because the actual and "should be" hostnames are identical.
>
> Cordially,
>
> Paul
>
> On Wed, Nov 6, 2013 at 5:52 PM, Andrew Phillips <an...@apache.org> wrote:
>>
>> You might want to try the following (haven't tested it, I have to say):
>>
>>
>> Properties overrides = new Properties();
>> overrides.setProperty(Constants.PROPERTY_TRUST_ALL_CERTS, "true");
>>
>> and then add this in to the context creation via
>> ".overrides(overrides).buildApi(...)"
>>
>> Hope this helps!
>>
>> ap
>
>
Re: Support for VMware vCloud Director
Posted by Paul Bell <ar...@gmail.com>.
Hi Andrew,
I made the change you suggested (thank you) and the symptom changed. I am
now getting this exception:
Exception in thread "main" org.jclouds.http.HttpResponseException:
org.jclouds.http.HttpResponseException: HTTPS hostname wrong: should be <
dpvcloud.mycompany.com> connecting to POST
https://dpvcloud.mycompany.com/sessions HTTP/1.1 connecting to GET
https://dpvcloud.mycompany.com/org/ HTTP/1.1
at
org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:162)
at
org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.invoke(InvokeSyncToAsyncHttpMethod.java:131)
at
org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:97)
at
org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod.apply(InvokeSyncToAsyncHttpMethod.java:58)
at
org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
at
com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:70)
at $Proxy56.list(Unknown Source)
at test.VcdTest.main(VcdTest.java:62)
Line 62 in my VcdTest.java is a call to orgApi.list().
I'm not sure how to interpret these phenomena, but I'd hazard the guess
that, prior to actually presenting the GET for "org", jclouds needs to
establish a session with VCD. Hence the POST for "sessions". I've done this
programmatically via the actual VCD REST API (as opposed to the Java SDK).
In response to this request, VCD is supposed to return an authorization
token that can then be used in the x-dpvcloud-authorization header.
In any event, it's hard to see why I'm getting a "hostname wrong" error
because the actual and "should be" hostnames are identical.
Cordially,
Paul
On Wed, Nov 6, 2013 at 5:52 PM, Andrew Phillips <an...@apache.org> wrote:
> You might want to try the following (haven't tested it, I have to say):
>
>
> Properties overrides = new Properties();
> overrides.setProperty(Constants.PROPERTY_TRUST_ALL_CERTS, "true");
>
> and then add this in to the context creation via ".overrides(overrides).
> buildApi(...)"
>
> Hope this helps!
>
> ap
>
Re: Support for VMware vCloud Director
Posted by Andrew Phillips <an...@apache.org>.
You might want to try the following (haven't tested it, I have to say):
Properties overrides = new Properties();
overrides.setProperty(Constants.PROPERTY_TRUST_ALL_CERTS, "true");
and then add this in to the context creation via
".overrides(overrides).buildApi(...)"
Hope this helps!
ap
Re: Support for VMware vCloud Director
Posted by Paul Bell <ar...@gmail.com>.
Understood, Andrew; thanks.
Moving along in my code, when I try to call, say, orgApi.list(), I am
getting a fairly obvious certificate-based authentication failure:
Exception in thread "main" org.jclouds.http.HttpResponseException:
org.jclouds.http.HttpResponseException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target connecting to POST
https://dpvcloud.myCompany.com/sessions HTTP/1.1 connecting to GET
https://dpvcloud.myCompany.com/org/ HTTP/1.1
In looking over some code I wrote last year - code that uses the VMware VCD
Java client - I noticed that, after instantiating the VcloudClient, I
called its registerScheme method passing it a protocol ("https"), a port
number (443), and an instance of an SSLSocketFactory. I provided a factory
that accepts self-signed certificates.
Is there some analog for this in jclouds?
Thanks.
Cordially,
Paul
On Wed, Nov 6, 2013 at 2:48 PM, Andrew Phillips <an...@apache.org> wrote:
> But, unless I am sorely mistaken (always possible!), I don't presently
>> have access to these abstractions for VCD.
>>
>
> No, you're not sorely mistaken (and good searching!) - there is no view
> abstraction yet for vcloud-director. Note the lack of a "view" element in
> the VCloudDirectorApiMetadata vs. the EC2ApiMetadata.
>
>
> If so, then won't my code - at least for the time being - be limited to a
>> single provider (VCD)?
>>
>
> Yes, that's correct.
>
>
> a. create one or more vApps, each consisting of one or more VMs.
>> b. deploy thereon an OVA/OVF
>> c. configure application specific stuff on these VMs
>> d. start them up
>>
>
> I don't know the exact calls to make for each of these, but the
> corresponding APIs should all be accessible from the VCloudDirectorApi.
>
> An easy way to find the appropriate calls is to look at the equivalent
> calls you would make via the underlying vCDC HTTP API.
>
> ap
>
> [1] https://github.com/jclouds/jclouds-labs/blob/master/
> vcloud-director/src/main/java/org/jclouds/vcloud/director/v1_5/
> VCloudDirectorApiMetadata.java#L79
> [2] https://github.com/jclouds/jclouds/blob/master/apis/ec2/
> src/main/java/org/jclouds/ec2/EC2ApiMetadata.java#L77
> [3] https://github.com/jclouds/jclouds-labs/blob/master/
> vcloud-director/src/main/java/org/jclouds/vcloud/director/
> v1_5/user/VCloudDirectorApi.java
>
Re: Support for VMware vCloud Director
Posted by Andrew Phillips <an...@apache.org>.
> But, unless I am sorely mistaken (always possible!), I don't
> presently have access to these abstractions for VCD.
No, you're not sorely mistaken (and good searching!) - there is no
view abstraction yet for vcloud-director. Note the lack of a "view"
element in the VCloudDirectorApiMetadata vs. the EC2ApiMetadata.
> If so, then won't my code - at least for the time being - be limited
> to a single provider (VCD)?
Yes, that's correct.
> a. create one or more vApps, each consisting of one or more VMs.
> b. deploy thereon an OVA/OVF
> c. configure application specific stuff on these VMs
> d. start them up
I don't know the exact calls to make for each of these, but the
corresponding APIs should all be accessible from the VCloudDirectorApi.
An easy way to find the appropriate calls is to look at the equivalent
calls you would make via the underlying vCDC HTTP API.
ap
[1]
https://github.com/jclouds/jclouds-labs/blob/master/vcloud-director/src/main/java/org/jclouds/vcloud/director/v1_5/VCloudDirectorApiMetadata.java#L79
[2]
https://github.com/jclouds/jclouds/blob/master/apis/ec2/src/main/java/org/jclouds/ec2/EC2ApiMetadata.java#L77
[3]
https://github.com/jclouds/jclouds-labs/blob/master/vcloud-director/src/main/java/org/jclouds/vcloud/director/v1_5/user/VCloudDirectorApi.java
Re: Support for VMware vCloud Director
Posted by Paul Bell <ar...@gmail.com>.
Hi again,
Making some progress now.
The "not wrappable as org.jclouds.compute.ComputeServiceContext" error that
I previously mentioned continues to occur. About this I discovered the
following:
http://mail-archives.apache.org/mod_mbox/jclouds-user/201309.mbox/%3c5228A784.3090606@gmail.com%3e
I think this is saying that the ComputeService implementation for VCD is
not yet finished. What does this mean? For example, per Andrew's
observation re using a provider-specific approach, am I presently
constrained to just such an approach? If so, then won't my code - at least
for the time being - be limited to a single provider (VCD)?
The comment in the mail archives indicates that, because the VCD domain
model is implemented, it's now possible to drive the underlying VCD REST
API via Java. But this capability was already present in the VMware Java
API for VCD.
Another question: if I am presently constrained to provider-specific API,
then will the first link that Andrew posted (MainApp.java) help me? That
is, it seems to deal in the nice jclouds abstractions, like "portable
views." But, unless I am sorely mistaken (always possible!), I don't
presently have access to these abstractions for VCD.
That said, I will quite happily study that code to learn more of the
jclouds idiom. But my immediate need is the ability to:
a. create one or more vApps, each consisting of one or more VMs.
b. deploy thereon an OVA/OVF
c. configure application specific stuff on these VMs
d. start them up
Again, thank you for your help & light.
Cordially,
Paul
On Wed, Nov 6, 2013 at 1:04 PM, Paul Bell <ar...@gmail.com> wrote:
> Hi Andrew,
>
> Thank you for this guidance.
>
> I will get on it!
>
> -Paul
>
> On Wed, Nov 6, 2013 at 12:36 PM, Andrew Phillips <an...@apache.org>wrote:
>
>> Hi Paul
>>
>> First of all, please use 1.6.2-incubating for all the dependencies, to
>> avoid any incompatibilities arising from that.
>>
>> As regards sample code, we're probably best off looking at the
>> compute-basics example [1] and the BaseVCloudDirectorApiLiveTest [2].
>>
>> If we want to work directly with the vendor-specific vCloud API, rather
>> than one of jclouds' portable views such as the ComputeServiceContext, we
>> can also get hold of the API directly, by the way:
>>
>> VCloudDirectorApi vcdApi =
>>
>> ContextBuilder.newBuilder("vcloud-director")
>> .endpoint("https://dpvcloud.company.com")
>> .credentials("pbell@MyOrg", "mypassword")
>> .buildApi(VCloudDirectorApi.class);
>>
>> See the ContextBuilder Javadoc [3] for more details.
>>
>> ap
>>
>> [1] https://github.com/jclouds/jclouds-examples/blob/master/
>> compute-basics/src/main/java/org/jclouds/examples/compute/
>> basics/MainApp.java
>> [2] https://github.com/jclouds/jclouds-labs/blob/master/
>> vcloud-director/src/test/java/org/jclouds/vcloud/director/v1_5/internal/
>> BaseVCloudDirectorApiLiveTest.java
>> [3] http://javadocs.jclouds.cloudbees.net/org/jclouds/ContextBuilder.html
>>
>
>
Re: Support for VMware vCloud Director
Posted by Paul Bell <ar...@gmail.com>.
Hi Andrew,
Thank you for this guidance.
I will get on it!
-Paul
On Wed, Nov 6, 2013 at 12:36 PM, Andrew Phillips <an...@apache.org> wrote:
> Hi Paul
>
> First of all, please use 1.6.2-incubating for all the dependencies, to
> avoid any incompatibilities arising from that.
>
> As regards sample code, we're probably best off looking at the
> compute-basics example [1] and the BaseVCloudDirectorApiLiveTest [2].
>
> If we want to work directly with the vendor-specific vCloud API, rather
> than one of jclouds' portable views such as the ComputeServiceContext, we
> can also get hold of the API directly, by the way:
>
> VCloudDirectorApi vcdApi =
>
> ContextBuilder.newBuilder("vcloud-director")
> .endpoint("https://dpvcloud.company.com")
> .credentials("pbell@MyOrg", "mypassword")
> .buildApi(VCloudDirectorApi.class);
>
> See the ContextBuilder Javadoc [3] for more details.
>
> ap
>
> [1] https://github.com/jclouds/jclouds-examples/blob/master/
> compute-basics/src/main/java/org/jclouds/examples/compute/
> basics/MainApp.java
> [2] https://github.com/jclouds/jclouds-labs/blob/master/
> vcloud-director/src/test/java/org/jclouds/vcloud/director/v1_5/internal/
> BaseVCloudDirectorApiLiveTest.java
> [3] http://javadocs.jclouds.cloudbees.net/org/jclouds/ContextBuilder.html
>
Re: Support for VMware vCloud Director
Posted by Andrew Phillips <an...@apache.org>.
Hi Paul
First of all, please use 1.6.2-incubating for all the dependencies, to
avoid any incompatibilities arising from that.
As regards sample code, we're probably best off looking at the
compute-basics example [1] and the BaseVCloudDirectorApiLiveTest [2].
If we want to work directly with the vendor-specific vCloud API,
rather than one of jclouds' portable views such as the
ComputeServiceContext, we can also get hold of the API directly, by
the way:
VCloudDirectorApi vcdApi =
ContextBuilder.newBuilder("vcloud-director")
.endpoint("https://dpvcloud.company.com")
.credentials("pbell@MyOrg", "mypassword")
.buildApi(VCloudDirectorApi.class);
See the ContextBuilder Javadoc [3] for more details.
ap
[1]
https://github.com/jclouds/jclouds-examples/blob/master/compute-basics/src/main/java/org/jclouds/examples/compute/basics/MainApp.java
[2]
https://github.com/jclouds/jclouds-labs/blob/master/vcloud-director/src/test/java/org/jclouds/vcloud/director/v1_5/internal/BaseVCloudDirectorApiLiveTest.java
[3] http://javadocs.jclouds.cloudbees.net/org/jclouds/ContextBuilder.html
Re: Support for VMware vCloud Director
Posted by Paul Bell <ar...@gmail.com>.
Hi,
Well, our VCD 1.5 is back up, but I'm having difficulty getting some
elementary stuff to work. I've little doubt that this is largely because
I'm not quite sure what I'm doing, but it's nonetheless frustrating.
At any rate, per instructions from folks on the list, I incorporated the
"labs" pom into my project. Pom now looks like this:
<dependency>
<groupId>org.apache.jclouds.labs</groupId>
<artifactId>vcloud-director</artifactId>
<version>1.6.2-incubating</version>
</dependency>
<dependency>
<groupId>org.apache.jclouds</groupId>
<artifactId>jclouds-all</artifactId>
<version>1.6.1-incubating</version>
</dependency>
<dependency>
<groupId>org.apache.jclouds.driver</groupId>
<artifactId>jclouds-sshj</artifactId>
<version>1.6.1-incubating</version>
</dependency>
I then tried to run this code:
ComputeServiceContext context =
ContextBuilder.newBuilder("vcloud-director")
.endpoint("https://dpvcloud.company.com")
.credentials("pbell@MyOrg", "mypassword")
//.overrides(overrides) - only if needed
.buildView(ComputeServiceContext.class);
This fails with the following (line 31 is the buildView call):
Exception in thread "main" java.lang.IllegalArgumentException: api
{id=vcloud-director, name=vCloud Director 1.5 API, views=[],
endpointName=https endpoint, identityName=User at Organization (user@org),
credentialName=Optional.of(Password), documentation=
http://www.vmware.com/support/pubs/vcd_pubs.html, api=interface
org.jclouds.vcloud.director.v1_5.user.VCloudDirectorApi, asyncApi=interface
org.jclouds.vcloud.director.v1_5.user.VCloudDirectorAsyncApi} not wrappable
as org.jclouds.compute.ComputeServiceContext; context:
org.jclouds.vcloud.director.v1_5.VCloudDirectorContext, views: []
at org.jclouds.ContextBuilder.buildView(ContextBuilder.java:616)
at org.jclouds.ContextBuilder.buildView(ContextBuilder.java:600)
at test.VcdTest.main(VcdTest.java:31)
Before I posted this, I looked fairly closely at the sources jar file to
see if I could find source code for the some of the test code, but to no
avail. If such test source code exists, can someone point me to them. Also,
could someone provide me an example of how to:
a. get logged into VCD
b. list vApps
c. define VMs and vApps
d. etc.?
Thanks.
Cordially,
Paul
On Tue, Nov 5, 2013 at 10:24 AM, Paul Bell <ar...@gmail.com> wrote:
> Thanks Ignasi and Andrew (nice timing by the way!).
>
> I will tend to this directly. Unfortunately, our in-house VCD seems to be
> down (mildly frustrating given my interest in getting going with jclouds).
>
> Cordially,
>
> Paul
>
> On Tue, Nov 5, 2013 at 10:20 AM, Andrew Phillips <an...@apache.org>wrote:
>
>> I right away hit a "provider not found" issue concerning provider
>>> "vcloud-director." I noticed in the list of extant providers (about 12
>>> tokens from the end) an entry for "vcloud." Should I be using this one
>>> instead?
>>>
>>
>> How is your project set up? "vcloud-director" is a labs provider, you'll
>> need to include it in your project dependencies explicitly:
>>
>> http://search.maven.org/#artifactdetails%7Corg.apache.
>> jclouds.labs%7Cvcloud-director%7C1.6.2-incubating%7Cbundle
>>
>> ap
>>
>
>
Re: Support for VMware vCloud Director
Posted by Paul Bell <ar...@gmail.com>.
Thanks Ignasi and Andrew (nice timing by the way!).
I will tend to this directly. Unfortunately, our in-house VCD seems to be
down (mildly frustrating given my interest in getting going with jclouds).
Cordially,
Paul
On Tue, Nov 5, 2013 at 10:20 AM, Andrew Phillips <an...@apache.org> wrote:
> I right away hit a "provider not found" issue concerning provider
>> "vcloud-director." I noticed in the list of extant providers (about 12
>> tokens from the end) an entry for "vcloud." Should I be using this one
>> instead?
>>
>
> How is your project set up? "vcloud-director" is a labs provider, you'll
> need to include it in your project dependencies explicitly:
>
> http://search.maven.org/#artifactdetails%7Corg.apache.
> jclouds.labs%7Cvcloud-director%7C1.6.2-incubating%7Cbundle
>
> ap
>
Re: Support for VMware vCloud Director
Posted by Andrew Phillips <an...@apache.org>.
> I right away hit a "provider not found" issue concerning provider
> "vcloud-director." I noticed in the list of extant providers (about 12
> tokens from the end) an entry for "vcloud." Should I be using this one
> instead?
How is your project set up? "vcloud-director" is a labs provider,
you'll need to include it in your project dependencies explicitly:
http://search.maven.org/#artifactdetails%7Corg.apache.jclouds.labs%7Cvcloud-director%7C1.6.2-incubating%7Cbundle
ap
Re: Support for VMware vCloud Director
Posted by Paul Bell <ar...@gmail.com>.
Hi Andrew,
Thank you for this guidance.
I right away hit a "provider not found" issue concerning provider
"vcloud-director." I noticed in the list of extant providers (about 12
tokens from the end) an entry for "vcloud." Should I be using this one
instead?
-Paul
Exception in thread "main" java.util.NoSuchElementException: key
[vcloud-director] not in the list of providers or apis:
{providers=[aws-cloudwatch, rackspace-cloudblockstorage-us,
rackspace-cloudblockstorage-uk, rackspace-clouddns-us,
rackspace-clouddns-uk, aws-sqs, aws-sts, aws-route53, ultradns-ws, dynect,
rackspace-cloudloadbalancers-uk, rackspace-cloudloadbalancers-us,
greenhousedata-element-vcloud, aws-ec2, cloudservers-us, cloudservers-uk,
trmk-vcloudexpress, trmk-ecloud, bluelock-vcloud-zone01, gogrid,
elastichosts-lon-p, elastichosts-sat-p, elastichosts-lon-b,
openhosting-east1, serverlove-z1-man, skalicloud-sdg-my, cloudsigma-zrh,
cloudsigma-lvs, go2cloud-jhb1, softlayer, ninefold-compute,
hpcloud-compute, rackspace-cloudservers-us, rackspace-cloudservers-uk,
aws-s3, ninefold-storage, cloudonestorage, azureblob, cloudfiles-us,
cloudfiles-uk, hpcloud-objectstorage], apis=[rackspace-cloudidentity,
openstack-keystone, openstack-cinder, rackspace-clouddns, cloudwatch, sqs,
sts, route53, rackspace-cloudloadbalancers, openstack-nova,
openstack-nova-ec2, byon, ec2, cloudservers, vcloud, cloudsigma,
elasticstack, cloudstack, s3, transient, atmos, swift, swift-keystone,
cloudfiles, filesystem, stub]}
at org.jclouds.ContextBuilder.newBuilder(ContextBuilder.java:176)
at test.VcdTest.main(VcdTest.java:24)
On Mon, Nov 4, 2013 at 7:45 PM, Andrew Phillips <an...@apache.org> wrote:
> I would be most grateful for some guidance in how to go about using
>> jclouds to talk "directly" to VMware's VCD.
>>
>
> You should be able to instantiate a context using the "plain"
> 'vcloud-director' API, setting (at minimum) the "endpoint" property for
> your target installation:
>
> Properties overrides = new Properties();
> overrides.setProperty(..., ...);
> overrides.setProperty(..., ...);
>
> ComputeServiceContext context = ContextBuilder.newBuilder("
> vcloud-director")
> .endpoint("https://your-vloud-ip-or-host/api")
> .credentials("user@org", "password")
> //.overrides(overrides) - only if needed
> .buildView(ComputeServiceContext.class);
>
> computeService = context.getComputeService();
> // do something with the compute service
>
> You can see some of the properties you can specific via the overrides in
> the API metadata [1]. You'll notice that providers using the vCloud
> Director API, such as Carrenza, effectively do just that in their provider
> metadata [2].
>
> What I don't know, however, is whether or how Whirr allows you to specify
> a context such as this one. One of the Whirr-savvy members of the list will
> hopefully be able to help out here!
>
> ap
>
> [1] https://github.com/jclouds/jclouds-labs/blob/master/
> vcloud-director/src/main/java/org/jclouds/vcloud/director/v1_5/
> VCloudDirectorApiMetadata.java#L59
> [2] https://github.com/jclouds/jclouds-labs/blob/master/
> carrenza-vcloud-director/src/main/java/org/jclouds/
> carrenza/vcloud/director/CarrenzaVCloudDirectorProviderMetadata.java#L69
>
Re: Support for VMware vCloud Director
Posted by Andrew Phillips <an...@apache.org>.
> I would be most grateful for some guidance in how to go about using
> jclouds to talk "directly" to VMware's VCD.
You should be able to instantiate a context using the "plain"
'vcloud-director' API, setting (at minimum) the "endpoint" property
for your target installation:
Properties overrides = new Properties();
overrides.setProperty(..., ...);
overrides.setProperty(..., ...);
ComputeServiceContext context = ContextBuilder.newBuilder("vcloud-director")
.endpoint("https://your-vloud-ip-or-host/api")
.credentials("user@org", "password")
//.overrides(overrides) - only if needed
.buildView(ComputeServiceContext.class);
computeService = context.getComputeService();
// do something with the compute service
You can see some of the properties you can specific via the overrides
in the API metadata [1]. You'll notice that providers using the vCloud
Director API, such as Carrenza, effectively do just that in their
provider metadata [2].
What I don't know, however, is whether or how Whirr allows you to
specify a context such as this one. One of the Whirr-savvy members of
the list will hopefully be able to help out here!
ap
[1]
https://github.com/jclouds/jclouds-labs/blob/master/vcloud-director/src/main/java/org/jclouds/vcloud/director/v1_5/VCloudDirectorApiMetadata.java#L59
[2]
https://github.com/jclouds/jclouds-labs/blob/master/carrenza-vcloud-director/src/main/java/org/jclouds/carrenza/vcloud/director/CarrenzaVCloudDirectorProviderMetadata.java#L69