[
https://issues.apache.org/jira/browse/JCLOUDS-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Gaul updated JCLOUDS-1165:
---------------------------------
Component/s: jclouds-compute
> 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
> Components: jclouds-compute
> 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.4.14#64029)
