[
https://issues.apache.org/jira/browse/JCLOUDS-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007750#comment-16007750
]
Ignasi Barrera commented on JCLOUDS-1290:
-----------------------------------------
+1 to use {{SecurityGroup.id()}}. The {{id}} field is the one used by and
understood by the portable abstraction. The providerId might not be enough to
uniquely identify a resource (for example in AWS the same id can reference
different instances in different regions), so we generate an ID the portable
abstraction can work with, and leave the real id in the providerId.
All references to IDs in portable code should reference the "portable IDs", so
using the providerId there looks wrong to me. We should fix the AWS provider.
> Inconsistency in IpPermission.groupId()
> ---------------------------------------
>
> Key: JCLOUDS-1290
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1290
> Project: jclouds
> Issue Type: Bug
> Reporter: Svetoslav Neykov
>
> When trying to add {{IpPermission}} allowing access from an existing
> {{SecurityGroup}} how should we initialise the {{IpPermission.groupId}} field
> from the {{SecurityGroup}} fields so it works across clouds?
> Using {{IpPermission.groupId == SecurityGroup.id()}} works for:
> * OpenStack (Bluebox)
> * Azure ARM
> Doesn't work for:
> * Amazon (Invalid id: "eu-west-1/sg-eb0a4292" (expecting "sg-..."))
> Using {{IpPermission.groupId == SecurityGroup.providerId()}} works for:
> * Amazon
> * Azure ARM
> Doesn't work for:
> * OpenStack (Bluebox) (id must be in format regionId/id)
> My understanding is that it should always work with {{SecurityGroup.id()}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
