jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aled Sage (JIRA)" <j...@apache.org>
Subject [jira] [Created] (JCLOUDS-1165) wrong loginUser inferred: add support for trying more possible loginUser values
Date Tue, 30 Aug 2016 14:04:20 GMT
Aled Sage created JCLOUDS-1165:

             Summary: wrong loginUser inferred: add support for trying more possible loginUser
                 Key: JCLOUDS-1165
                 URL: https://issues.apache.org/jira/browse/JCLOUDS-1165
             Project: jclouds
          Issue Type: Improvement
    Affects Versions: 1.9.2
            Reporter: Aled Sage

Sometimes when provisioning VMs, provisioning fails because ssh'ing to the VM fails - it is
the wrong {{loginUser}}.

The workaround is simple: to figure out the right loginUser for the VM image that is being
chosen, and to call {{templateOptions.overrideLoginUser()}}.

For situations where the default loginUser is wrong, I'd like alternative ones to also be

One way would be to add {{TemplateOptions.fallbackLoginUsers(Iterable<String> fallbackLoginUsers)}}.
When waiting for the first ssh connection, it could try these fallbacks as well. The first
user to work with the given credentials could then be used subsequently.

If this option were available, I'd probably always pass in {{templateOptions.fallbackLoginUsers(ImmutableList.of("root",
"centos", "ubuntu", "ec2-user"))}}.

Another option would be that if there is no explicit (i.e. no overridden) login user in the
templateOptions, then we try a bunch of stock users. We could adjust the existing {{PopulateDefaultLoginCredentialsForImageStrategy}}
to return a set of {{LoginCredentials}} to try - but that would be a bit harder to change
while preserving backwards compatibility.

The existing logic to figure out the default loginUser looks pretty scary - for example, [1,
2, 3]. There are hard-coded rules for whether to use "ubuntu", "ec2-user", etc based on the
OS type, the cloud provider, and the image owner! I had previously thought that image metadata
from the cloud provider would tell us the right loginUser, but I guess that's not the case!

The workaround is to explicitly set the loginUser in the location definition.
[1] https://github.com/jclouds/jclouds/blob/rel/jclouds-1.9.2/apis/ec2/src/main/java/org/jclouds/ec2/compute/strategy/EC2PopulateDefaultLoginCredentialsForImageStrategy.java#L63-L67
[2] https://github.com/jclouds/jclouds/blob/rel/jclouds-1.9.2/compute/src/main/java/org/jclouds/compute/strategy/impl/ReturnCredentialsBoundToImage.java
[3] https://github.com/jclouds/jclouds/blob/rel/jclouds-1.9.2/apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/compute/config/NovaComputeServiceContextModule.java#L190-L193

This message was sent by Atlassian JIRA

View raw message