Since createNodesInGroup() accepts group name as a parameter am I correct to assume that the current logic with key pairs and security groups should be ignored in this case and the name provided should be used as the group name? Also, if I created security group and/or key together with the node, would the group name be respected or would Jclouds still try to come up with it's own name? As a workaround I will try to manually create metadata tag for group name.
To explain my use case a bit further, I want to group the nodes by operating system, so I can select nodes like: "Give me all Ubuntu nodes" or "Give me all FreeBSD nodes" or "Give me all Windows nodes" etc. That is why I want to provide the group name by myself which is basically "MyProjectName"+amiId. On 21. 03. 2016 11:29, Ignasi Barrera wrote: > Regarding the group names thing, jclouds tries to infer the group name > from the security groups and key pairs [1]. When key pairs or security > groups are (indirectly) created as part of the "createNodesInGroup" > call, jclouds applies the naming convention taking into account the > group name. The code that tries to infer the groups for existing > instances seems to rely on that fact, which conflicts with the use > case when security groups or key pairs already exist or are created > using the security group extension (which has no "group" parameter). > > This could definitely be done better by applying tags to the created > instance, or whatever, so mind filing a JIRA issue with the code > snippet you pasted, so we can properly track and improve this? > > > > I. > > [1] > https://github.com/jclouds/jclouds/blob/master/apis/ec2/src/main/java/org/jclouds/ec2/compute/functions/RunningInstanceToNodeMetadata.java#L186-L194 > [2] https://issues.apache.org/jira/browse/JCLOUDS > > On 20 March 2016 at 13:31, Andrew Phillips <andr...@apache.org> wrote: >> >> >> 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
