Re: Retrieving provider specific details using JClouds

[Shruti Mehra]

Thank you for all the help!

On Monday, August 12, 2013, Andrew Phillips  wrote:
>> for Whirr project which is build on jclouds. Here in the apply method,
they
>> are actually maintaining a Map named "extra" while mapping a runnning
>> instance to node metadata. Do you think it solves the purpose I earlier
>> mentioned?
>
> I'm not familiar with the Whirr codebase myself; hopefully one of the
committers can provide more details. It might be a question you'd like to
ask in a Whirr forum, actually.
>
> ap
>

-- 
Thanks and Regards,
Shruti Mehra

Re: Retrieving provider specific details using JClouds

[Andrew Phillips]

for Whirr project which is build on jclouds. Here in the apply method, they
are actually maintaining a Map named "extra" while mapping a runnning
instance to node metadata. Do you think it solves the purpose I earlier
mentioned?


I'm not familiar with the Whirr codebase myself; hopefully one of the  
committers can provide more details. It might be a question you'd like  
to ask in a Whirr forum, actually.


ap

Re: Retrieving provider specific details using JClouds

[Shruti Mehra]

True, the reasons  mentioned by you hold true but the userMetadata still
misses on a lot of properties.

On a different note, I came across this
code
for Whirr project which is build on jclouds. Here in the apply method, they
are actually maintaining a Map named "extra" while mapping a runnning
instance to node metadata. Do you think it solves the purpose I earlier
mentioned? Although, it is in its initial stages as of now.

-- 
Thanks and Regards,
Shruti Mehra

Re: Retrieving provider specific details using JClouds

[Andrew Phillips]

Going by the unwrap() way would require us to be provider-aware and hence
losing out on having a generic code. On the other hand, having key-value
pair would just require skimming through the map, irrespective of any
provider. If only it exists :)


The closest you can get to that is NodeMetadata.userMetdata [1], which  
every provider may populate differently.


As regards just getting "all the other" properties of an object in  
some kind of "other" collection: two reasons I can recall why jclouds  
does not do this is that


* you lose any kind of typed domain model and
* you end up writing code similar to "if  
(otherPropertiesBag.containsKey("someProperty")) { ... }", which is  
basically a form of provider-specific code.


Of course, it's true that  
"otherPropertiesBag.contains("pricingModel")" is less explicitly  
provider-specific than "targetApi == "aws-ec2", but in order to be  
able to correctly understand what "pricingModel" means you pretty much  
have to know which provider or provider class you're talking to.


ap

[1]  
http://javadocs.jclouds.cloudbees.net/org/jclouds/domain/ResourceMetadata.html#getUserMetadata()

Re: Retrieving provider specific details using JClouds

[Shruti Mehra]

Thank you Andrew.

The unwrap() method works just fine. But I was wondering if JClouds has
provision for something on the following guidelines:

The nodes/instances that we receive from the generic jclouds call populates
the following fields
   private final Status status;
   private final String backendStatus;
   private final int loginPort;
   private final Set publicAddresses;
   private final Set privateAddresses;
   @Nullable
   private final LoginCredentials credentials;
   @Nullable
   private final String group;
   @Nullable
   private final String imageId;
   @Nullable
   private final Hardware hardware;
   @Nullable
   private final OperatingSystem os;
   @Nullable
   private final String hostname;

Is there any provision in JClouds where the rest of the provider-specific
attributes for a particular instance/node are stored in key value pair
form?
Going by the unwrap() way would require us to be provider-aware and hence
losing out on having a generic code. On the other hand, having key-value
pair would just require skimming through the map, irrespective of any
provider. If only it exists :)


On Wed, Aug 7, 2013 at 7:13 PM, Andrew Phillips  wrote:

> Here the nodes will be represented using NodeMetaData having standard
>> attributes which hold true for all the cloud providers. What if I wish to
>> access say aws-ec2 specific attributes without compromising on the generic
>> code which hold true across vendors?
>>
>
> If you need to get access at AWS-specific APIs or classes, you can
> "unwrap" [1] the context to access the underlying API [2]:
>
> AWSEC2Api awsApi = context.unwrapApi(AWSEC2Api.**class);
>
> If you only use the API in places where provider-specific logic is
> required, the remainder of the code should remain generic. See this recent
> thread [3] for an example of testing for a specific backing provider before
> unwrapping.
>
> ap
>
> [1] http://javadocs.jclouds.**cloudbees.net/org/jclouds/**
> View.html#unwrapApi(java.lang.**Class)
> [2] https://github.com/jclouds/**jclouds/blob/master/providers/**
> aws-ec2/src/main/java/org/**jclouds/aws/ec2/AWSEC2Api.java
> [3] 
> http://apache.markmail.org/**thread/g24ahltkamzf6bpp
>



-- 
Thanks and Regards,
Shruti Mehra

Re: Retrieving provider specific details using JClouds

[Andrew Phillips]

I thought unwrapApi wasn't available on async-enabled services...


Sorry, yes, indeed. "unwrapApi" is only available on the current  
1.7.0-SNAPSHOT.


Thanks for clarifying, abayer!

ap

Re: Retrieving provider specific details using JClouds

[Andrew Bayer]

Actually, in 1.6, don't you still need to go the CONTEXT_TOKEN route? i.e.,

EC2Client ec2Client =
computeServiceContext.unwrap(EC2ApiMetadata.CONTEXT_TOKEN).getApi()

I thought unwrapApi wasn't available on async-enabled services...

A.

On Wed, Aug 7, 2013 at 6:43 AM, Andrew Phillips  wrote:

> Here the nodes will be represented using NodeMetaData having standard
>> attributes which hold true for all the cloud providers. What if I wish to
>> access say aws-ec2 specific attributes without compromising on the generic
>> code which hold true across vendors?
>>
>
> If you need to get access at AWS-specific APIs or classes, you can
> "unwrap" [1] the context to access the underlying API [2]:
>
> AWSEC2Api awsApi = context.unwrapApi(AWSEC2Api.**class);
>
> If you only use the API in places where provider-specific logic is
> required, the remainder of the code should remain generic. See this recent
> thread [3] for an example of testing for a specific backing provider before
> unwrapping.
>
> ap
>
> [1] http://javadocs.jclouds.**cloudbees.net/org/jclouds/**
> View.html#unwrapApi(java.lang.**Class)
> [2] https://github.com/jclouds/**jclouds/blob/master/providers/**
> aws-ec2/src/main/java/org/**jclouds/aws/ec2/AWSEC2Api.java
> [3] 
> http://apache.markmail.org/**thread/g24ahltkamzf6bpp
>

Re: Retrieving provider specific details using JClouds

[Andrew Phillips]

Here the nodes will be represented using NodeMetaData having standard
attributes which hold true for all the cloud providers. What if I wish to
access say aws-ec2 specific attributes without compromising on the generic
code which hold true across vendors?


If you need to get access at AWS-specific APIs or classes, you can  
"unwrap" [1] the context to access the underlying API [2]:


AWSEC2Api awsApi = context.unwrapApi(AWSEC2Api.class);

If you only use the API in places where provider-specific logic is  
required, the remainder of the code should remain generic. See this  
recent thread [3] for an example of testing for a specific backing  
provider before unwrapping.


ap

[1]  
http://javadocs.jclouds.cloudbees.net/org/jclouds/View.html#unwrapApi(java.lang.Class)
[2]  
https://github.com/jclouds/jclouds/blob/master/providers/aws-ec2/src/main/java/org/jclouds/aws/ec2/AWSEC2Api.java

[3] http://apache.markmail.org/thread/g24ahltkamzf6bpp