unsubscribe
Re: Support for VMware vCloud Director
Excellent; thank you. -Paul On Thu, Nov 7, 2013 at 10:58 AM, Ignasi 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 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 > > 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 > 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
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 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
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 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
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.3090...@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 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 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
Hi Andrew,
Thank you for this guidance.
I will get on it!
-Paul
On Wed, Nov 6, 2013 at 12:36 PM, Andrew Phillips 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
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:
org.apache.jclouds.labs
vcloud-director
1.6.2-incubating
org.apache.jclouds
jclouds-all
1.6.1-incubating
org.apache.jclouds.driver
jclouds-sshj
1.6.1-incubating
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 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 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: VMware's vCAC?
Thanks, Bk. I also found this: http://up2v.nl/2013/08/29/vmware-vcloud-director-is-approaching-end-of-life/ which, I think, quotes from the VMware blog you referenced. A cursory read of these articles suggests that VCD will continue to exist, but it's being targeted to the service provider realm. VMware seems to be positioning vCAC for their "enterprise customers." -Paul On Tue, Nov 5, 2013 at 12:00 PM, Bk Lau wrote: > This link might help: > > > http://blogs.vmware.com/vsphere/2013/09/vcloud-director-convergence-and-transition-plan-whats-the-scoop.html > > > On Tue, Nov 5, 2013 at 11:23 AM, Andrew Phillips wrote: > >> No sooner did I get started with jclouds and VMware's vCloud Director, >>> than >>> I am reminded by a colleague about VMware's new "vCloud Automation >>> Center." >>> >>> Is vCAC something that will affect the development of jclouds, i.e., will >>> you have to program for it? >>> >> >> At this point you know more about vCAC than certainly I do! I have no >> idea how it may or may not impact usage of vCloud via jclouds; all I can >> say is that, as far as I know, nothing vCloud or vCAC-related is >> specifically on the jclouds roadmap for 1.7.x at this time. >> >> ap >> > >
VMware's vCAC?
Hi, No sooner did I get started with jclouds and VMware's vCloud Director, than I am reminded by a colleague about VMware's new "vCloud Automation Center." Is vCAC something that will affect the development of jclouds, i.e., will you have to program for it? At this point I know very little about vCAC. A cursory read of various blogs suggests that it can be used to stand up a Cloud without any VCD at all. Other articles suggest that vCAC is more of a presentation & orchestration layer built atop (and abstracting resources from) VCD. Thanks. Cordially, Paul
Re: Support for VMware vCloud Director
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 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
Hi again,
I should have mentioned that I am using the 1.6.1 incubating release. Well,
the project POM contains:
org.apache.jclouds
jclouds-all
1.6.1-incubating
org.apache.jclouds.driver
jclouds-sshj
1.6.1-incubating
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 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
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 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
>
