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