You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by "Ignasi Barrera (JIRA)" <ji...@apache.org> on 2017/05/12 07:40:04 UTC
[jira] [Commented] (JCLOUDS-1290) Inconsistency in
IpPermission.groupId()
[ 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)