Re: requested location eu-central-1, which is not in the configured locations

[Andrew Gaul]

I can confirm that the aws-s3 provider still uses the v2 signatures.  I
committed several fixes for the v4 signatures in JCLOUDS-766 but one
blocking issue remains.  v4 URL signing requires a content hash for the
server to accept the PUT request but the jclouds API does not allow for
this.  One workaround would be to use v2 signatures for jclouds URL
signing and v4 signatures for other requests, which would work for most
regions.  If you can live without this functionality, please use the
following branch for now:

https://github.com/andrewgaul/jclouds/tree/aws-signature-v4

Unfortunately I cannot work on this further for a few weeks.  Let's
track further discussion with JCLOUDS-1090.

On Wed, Mar 09, 2016 at 11:57:53PM +0530, Ranjith R wrote:
> Hi,
>I would also like to know how to use AWS S3 v4 signature for
> authentication.  Is there way to specify which signature version to use
> while constructing a BlobStoreContext?
> 
> Thanks in advance,
> Ranjith
> 
> On Tue, Mar 8, 2016 at 3:24 PM, Archana C  wrote:
> 
> > From the amazon documentation, we understand that the region eu-central-1
> > (Frankfurt) supports only AWS signature version 4, and from
> > https://issues.apache.org/jira/browse/JCLOUDS-480 we understand the
> > jclouds already has the support added for version 4 signature.
> >
> > What we are trying to figure out is *if* we need to do anything from the
> > client side to change the authorization signature.  We were hoping the
> > BlobStore APIs might work it used to with out changing the client code,
> > however, we see the requests sent are using V2 signature, and the server is
> > rejecting them.
> >
> > 2016-03-08 14:57:57,044 DEBUG [jclouds.wire] [main] >> "Test[\n]"
> > 2016-03-08 14:57:57,045 DEBUG [jclouds.headers] [main] >> PUT
> > https://testcontainer3.s3-eu-central-1.amazonaws.com/file1 HTTP/1.1
> > 2016-03-08 14:57:57,045 DEBUG [jclouds.headers] [main] >> Expect:
> > 100-continue
> > 2016-03-08 14:57:57,045 DEBUG [jclouds.headers] [main] >> Host: 
> > *testcontainer3.s3-eu-central-1.amazonaws.com
> > *
> > 2016-03-08 14:57:57,045 DEBUG [jclouds.headers] [main] >> Date: Tue, 08
> > Mar 2016 09:27:50 GMT
> > *2016-03-08 14:57:57,045 DEBUG [jclouds.headers] [main] >> Authorization:
> > AWS AKIAISCW6DRRITWR6IWQ:6AndVHQV2w75OXQDq/9sWt37KN0=*
> > 2016-03-08 14:57:57,045 DEBUG [jclouds.headers] [main] >> Content-Type:
> > application/unknown
> > 2016-03-08 14:57:57,045 DEBUG [jclouds.headers] [main] >> Content-Length: 5
> >
> > *org.jclouds.http.HttpResponseException: Server rejected operation
> > connecting to PUT
> > https://testcontainer3.s3-eu-central-1.amazonaws.com/file1
> >  HTTP/1.1*
> > * at
> > org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:118)*
> > * at
> > org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:90)*
> > * at
> > org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:73)*
> > * at
> > org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:44)*
> >
> > *Any help on how to use the AWS version 4 signature for the blobstore APIs
> > will be much appreciated. *
> >
> > *NB: With the last commit mentioned in the above reply, we do not see the
> > region not supported exception anymore. *
> >
> > *Thanks!*
> >
> > *Regards*
> >
> > *Archana*
> > 
> >
> >
> > On Tuesday, 8 March 2016, 10:54, Andrew Gaul  wrote:
> >
> >
> > Please test again with the latest master which includes a fix:
> >
> > https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=commit;h=c18371a7
> >
> > On Mon, Mar 07, 2016 at 12:29:59PM +, Archana C wrote:
> > > public class App
> > > {
> > > public static void main( String[] args ) throws IOException
> > > {
> > > // TODO Auto-generated method stub
> > > // TODO Auto-generated method stub
> > > String containername = "archanatrial12";
> > > String objectname = "object1";
> > > String tempFile =
> > "/home/archana/Eclipse/trialV42/src/main/java/trialV41/trialV42/result.txt";
> > > //int length;
> > >
> > > // s3.amazonaws.com   s3.eu-central-1.amazonaws.com
> > s3-external-1.amazonaws.com
> > >
> > > BlobStoreContext context =
> > ContextBuilder.newBuilder("aws-s3")
> > > .credentials("XXX",
> > "YYY")
> > > .buildView(BlobStoreContext.class);
> > >
> > > // Access the BlobStore
> > > BlobStore blobStore = context.getBlobStore();
> > > //Location loc = "us-east-1";
> > > Location loc = new
> > LocationBuilder().scope(LocationScope.REGION)
> > >

Re: Group name not set for new nodes on EC2

[Andrew Phillips]

On 2016-03-20 10:00, cen wrote:

Agree with both statements. If there was documentation about this on
createSecurityGroup I'd knew instantly what is going on. It could even
be a generic statement that a certain method adheres to
GroupNamingConvention.

The pattern does not really match my use case because I create a single
security group on first run and then re-use it for each new VM (that's
why I hardcoded the name).


Ah, like that - in that case, I would imagine Ignasi's suggestion of 
either setting the RESOURCENAME_PREFIX property, or going a step further 
and actually overriding the naming convention "generator", might be the 
right thing to do?


Then you *know* exactly what the resources will look like, and don't 
have to save that information for reuse later.


Regards

ap

Re: Group name not set for new nodes on EC2

[cen]

Agree with both statements. If there was documentation about this on
createSecurityGroup I'd knew instantly what is going on. It could even
be a generic statement that a certain method adheres to
GroupNamingConvention.

The pattern does not really match my use case because I create a single
security group on first run and then re-use it for each new VM (that's
why I hardcoded the name). I'd probably have to save the name to
database in this case and I think that's what I'll actually do.

On 19. 03. 2016 17:58, Andrew Phillips wrote:
>>> Regarding the group name in the nodes, could you share the code you
>>> use to build the template, including the template options?
> 
> Thanks for the additional details! More information on the resource
> prefixing Ignasi was mentioning is here, by the way:
> 
> http://jclouds.apache.org/reference/javadoc/1.9.x/org/jclouds/compute/functions/GroupNamingConvention.html
> 
> 
> Still, it seems we are short on documentation on where exactly this
> prefixing is applied. For example, the documentation for
> createSecurityGroup [1] does not mention this, even though from the code
> [2] and what we've seen in this thread a prefix *is* being added.
> 
> In order to avoid this problem, would it make sense to recommend the
> following pattern?
> 
> SecurityGroup sg = securityGroupExtension.createSecurityGroup("name",
> region);
> 
> // get the name of the actually created item!!
> String sgName = sg.getName();
> ...
> EC2TemplateOptions o = EC2TemplateOptions.Builder.securityGroups(sgName);
> ...
> 
> In other words, instead of assuming that the input parameter to
> createSecurityGroup (or similar calls) can be used as-is, always use the
> values of the resulting object?
> 
> Regards
> 
> ap
> 
> [1]
> http://jclouds.apache.org/reference/javadoc/1.9.x/org/jclouds/aws/ec2/compute/extensions/AWSEC2SecurityGroupExtension.html#createSecurityGroup(java.lang.String,
> java.lang.String)
> [2]
> https://github.com/jclouds/jclouds/blob/master/providers/aws-ec2/src/main/java/org/jclouds/aws/ec2/compute/extensions/AWSEC2SecurityGroupExtension.java#L73
>