You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by "Richard Downer (Cloudsoft) (JIRA)" <ji...@apache.org> on 2013/08/14 17:35:49 UTC

[jira] [Updated] (JCLOUDS-242) EC2 create security group error

     [ https://issues.apache.org/jira/browse/JCLOUDS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Downer (Cloudsoft) updated JCLOUDS-242:
-----------------------------------------------

    Attachment: jclouds-security-group-ingress-error.log
    
> EC2 create security group error
> -------------------------------
>
>                 Key: JCLOUDS-242
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-242
>             Project: jclouds
>          Issue Type: Bug
>          Components: jclouds-compute
>    Affects Versions: 1.6.2
>            Reporter: Richard Downer (Cloudsoft)
>         Attachments: jclouds-security-group-ingress-error.log
>
>
> 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!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira