jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCLOUDS-1165) wrong loginUser inferred: add support for trying more possible loginUser values
Date Thu, 15 Dec 2016 12:09:58 GMT

    [ https://issues.apache.org/jira/browse/JCLOUDS-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751210#comment-15751210

ASF GitHub Bot commented on JCLOUDS-1165:

Github user aledsage commented on the issue:

    @drigodwin interesting. I'm not sure who we should optimise for though, with the defaults.
    The problem is if someone has misconfigured their location. For example, 
    we'll wait several minutes for sshable before reporting provisioning as failed. It's annoying
that it takes 20 minutes (or whatever) to tell you that provisioning has failed. If we set
`machineCreateAttempts=3` then it will take 60 minutes before it tells you that it's failed.
    It's a particular concern because of problems like https://issues.apache.org/jira/browse/JCLOUDS-1165,
which can hit someone using the defaults in a common cloud (e.g. aws-ec2).
    Maybe we compromise with `machineCreateAttempts=2`?
    Much longer term, we could try to make the activities view clearer, to show that it's
moved onto attempt number 2 (cc @m4rkmckenna @tbouron). That probably would require some significant
restructuring of the low-level tasks executed for provisioning though.

> 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

View raw message