[
https://issues.apache.org/jira/browse/JCLOUDS-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583367#comment-14583367
]
Ignasi Barrera commented on JCLOUDS-861:
----------------------------------------
[~yaronr] now GCE properly sets the default user for CoreOS images. The
bootstrap is working as expected in CentOS, Debian and the other templates, but
the way CoreOS works makes the connection to fail, as you pointed out.
If setting the cloud-init file during the node provisioning fixes it, do you
think it would be a good idea to create a default cloud init file if the image
being deployed is a CoreOS image? Is so, which would be the right contents for
such a minimal default cloud init configuration to enable SSH access to the
node?
[~broudy] WDYT about the proper way to fix this? Should we leave the
implementation as-is and let the user provide the cloud-init file in the
usermetadata, or should we generate one on the fly (only for CoreOS images, if
missing) to enable SSH access?
> node creation fails due to ssh failure
> --------------------------------------
>
> Key: JCLOUDS-861
> URL: https://issues.apache.org/jira/browse/JCLOUDS-861
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-labs-google
> Reporter: Yaron Rosenbaum
> Priority: Minor
> Labels: google-compute-engine
>
> I am creating CoreOS nodes, and using cloud-init with them. The cloud-init
> takes a while to process.
> 11:42:32.780 [user thread 3] ERROR jclouds.ssh - <<
> (core:rsa[ssh-agent]@1….2) error acquiring {hostAndPort=1…2:22,
> loginUser=core, ssh=null, connectTimeout=60000, sessionTimeout=60000} (not
> retryable): Exhausted available authentication methods
> net.schmizz.sshj.userauth.UserAuthException: Exhausted available
> authentication methods
> I’ve set the following overrides:
>
> overrides.setProperty(ComputeServiceProperties.POLL_INITIAL_PERIOD,
> TWENTY_SECONDS);
> overrides.setProperty(ComputeServiceProperties.POLL_MAX_PERIOD,
> TWENTY_SECONDS);
> // 18 retries of 15 seconds --> 4.5 min
> overrides.setProperty(Constants.PROPERTY_MAX_RETRIES, "6");
> overrides.setProperty(Constants.PROPERTY_RETRY_DELAY_START, "15");
> These overrides had no effect.
> overrides.setProperty("jclouds.ssh.max-retries", "100");
> overrides.setProperty("jclouds.ssh.retry-auth", "true");
> These overrides worked - ssh retries for 100 times, but: the sleep time
> between retries is 2s (which should be exponential backoff, and configurable)
> and - eventually locks down the ssh agent for "too many retries"
> (the ssh agent is up, it's only that the ssh key was not installed yet...)
> My workaround is to install ssh keys as part of cloud-init, and then
> everything works ok, but this is a serious bug, and this workaround will not
> work in all cases.
> This MAY be related to:
> https://github.com/jclouds/jclouds-labs-google/pull/118
> PS.
> I setup cloud-init by setting user metadata “user-data”=<the content of the
> cloud-init.yaml file>.
> cloud-init works, node IS accessible via ssh, and my unit files are up and
> running.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
