jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cen <imba...@gmail.com>
Subject Re: Group name not set for new nodes on EC2
Date Mon, 21 Mar 2016 23:49:43 GMT
Issue opened as requested: 
https://issues.apache.org/jira/browse/JCLOUDS-1096

I'll post a workaround here if I find a good one.

Ignasi Barrera je 21. 03. 2016 ob 12:17 napisal:
> 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 <imbacen@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 <andrewp@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


Mime
View raw message