[jira] [Created] (JCLOUDS-1165) wrong loginUser inferred: add support for trying more possible loginUser values

["Aled Sage (JIRA)" <ji...@apache.org>]

Aled Sage created JCLOUDS-1165:
----------------------------------

             Summary: wrong loginUser inferred: add support for trying more possible loginUser values
                 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 tried.

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
(v6.3.4#6332)