Well, jclouds will create key pairs based on the login credentials. If you provide the "login private key" option, jclouds will create a key pair for it, if it still doesn't exist, and generate a unique name for the key pair based on the group name (using the mentioned group naming convention that use the prefix variables, etc). The security groups are a bit more rudimentary, as the generic template options just allow you to set the "inboundPorts" (the other option is to pass the names of already existing groups). When this option is set, jclouds will create the security groups the same way.
Given your use case, perhaps you can also filter nodes by their operating system information. jclouds will try to infer the operating system from the image, and it is likely you could use that information to filter the nodes. You can have a look at the existing OperatingSystemPredicates [1] class to see the kind of info you can query. [1] https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/predicates/OperatingSystemPredicates.java On 21 March 2016 at 11:52, cen <imba...@gmail.com> wrote: > 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
