Details
-
Bug
-
Status: Resolved
-
Blocker
-
Resolution: Fixed
-
1.6.2
-
None
Description
While preparing an application to support jclouds-1.6.2, testing against RC1, I discovered that when using AWS EC2 and invoking createNodesInGroup(...) with a group name not used before, jclouds will cause AWS to emit an error "InvalidGroupId.Malformed" when invoking API call AuthorizeSecurityGroupIngress. This problem does not occur in 1.6.1-incubating.
Example:
TemplateOptions options = computeService.templateOptions()
.blockOnPort(22, 600)
.inboundPorts(22, 80);
Template template = computeService.templateBuilder()
.options(options)
.build();
Set<? extends NodeMetadata> nodes = computeService.createNodesInGroup("a-never-seen-before-group-name", 1, template);
Outcome:
Here is an extract from the jclouds log: (a bigger log extract is attached)
62496|DEBUG|main |org.jclouds.rest.internal.InvokeSyncToAsyncHttpMethod |>> invoking AuthorizeSecurityGroupIngress
62499|DEBUG|main |org.jclouds.http.internal.JavaUrlHttpCommandExecutorService|Sending request -1187121582: POST https://ec2.us-east-1.amazonaws.com/ HTTP/1.1
62499|DEBUG|main |jclouds.wire |>> "Action=AuthorizeSecurityGroupIngress&GroupId=jclouds%23richard-new-group3&IpPermissions.0.FromPort=80&IpPermissions.0.IpProtocol=tcp&IpPermissions.0.IpRanges.0.CidrIp=0.0.0.0/0&IpPermissions.0.ToPort=80&IpPermissions.1.FromPort=22&IpPermissions.1.IpProtocol=tcp&IpPermissions.1.IpRanges.0.CidrIp=0.0.0.0/0&IpPermissions.1.ToPort=22&IpPermissions.2.FromPort=0&IpPermissions.2.Groups.0.GroupName=jclouds%23richard-new-group3&IpPermissions.2.Groups.0.UserId=761990928256&IpPermissions.2.IpProtocol=tcp&IpPermissions.2.ToPort=65535&IpPermissions.3.FromPort=0&IpPermissions.3.Groups.0.GroupName=jclouds%23richard-new-group3&IpPermissions.3.Groups.0.UserId=761990928256&IpPermissions.3.IpProtocol=udp&IpPermissions.3.ToPort=65535&Signature=8TclhF%2Bm78/A8sbqAArV5FiAjw/s61tDyRHWbaVmNlY%3D&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-08-14T15%3A09%3A12.069Z&Version=2012-06-01&AWSAccessKeyId=AKIAJN65AYF37RPSZB5A"
62499|DEBUG|main |jclouds.headers |>> POST https://ec2.us-east-1.amazonaws.com/ HTTP/1.1
62499|DEBUG|main |jclouds.headers |>> Host: ec2.us-east-1.amazonaws.com
62499|DEBUG|main |jclouds.headers |>> Content-Type: application/x-www-form-urlencoded
62499|DEBUG|main |jclouds.headers |>> Content-Length: 922
62653|DEBUG|main |org.jclouds.http.internal.JavaUrlHttpCommandExecutorService|Receiving response -1187121582: HTTP/1.1 400 Bad Request
62653|DEBUG|main |jclouds.headers |<< HTTP/1.1 400 Bad Request
62653|DEBUG|main |jclouds.headers |<< Transfer-Encoding: chunked
62653|DEBUG|main |jclouds.headers |<< Date: Wed, 14 Aug 2013 15:09:11 GMT
62653|DEBUG|main |jclouds.headers |<< Cneonction: close
62653|DEBUG|main |jclouds.headers |<< Server: AmazonEC2
62653|DEBUG|main |jclouds.headers |<< Content-Type: application/unknown
62654|DEBUG|main |jclouds.wire |<< "<?xml version="1.0" encoding="UTF-8"?>[\n]"
62654|DEBUG|main |jclouds.wire |<< "<Response><Errors><Error><Code>InvalidGroupId.Malformed</Code><Message>Invalid id: "jclouds#richard-new-group3" (expecting "sg-...")</Message></Error></Errors><RequestID>91ad5fb8-3e93-4566-8d6e-952518c766d8</RequestID></Response>"
com.google.common.util.concurrent.UncheckedExecutionException: java.lang.IllegalArgumentException: Invalid id: "jclouds#richard-new-group3" (expecting "sg-...")
After the test, seems that the security group is created but ingress rules are not configured. Running the test for a second time, jclouds sees that the security group exists so does not attempt to create or configure it. Therefore, on the second run, the test fails because it is unable to get access to port 22.
—
This may be caused by the changes in commit 7ac0d37 for JCLOUDS-99. This is invoking this API call:
securityClient.authorizeSecurityGroupIngressInRegion(region, name, perms);
However, inspecting the definition of this API call, it takes a security group id - not a name. This code is sending the name instead of the ID, and AWS rejects it as being an unknown ID.
It seems that confusion has been caused by the definitions of authorizeSecurityGroupIngressInRegion. In the class SecurityGroupAsyncClient, both methods by this name take the group name as a parameter. It is subclassed by AWSSecurityGroupAsyncClient which adds two more authorizeSecurityGroupIngressInRegion methods, that take the group id as a parameter. This is obviously a very confusing inconsistency!