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

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ 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:

    https://github.com/apache/brooklyn-server/pull/487
  
    @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
(v6.3.4#6332)