[
https://issues.apache.org/jira/browse/WHIRR-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13135756#comment-13135756
]
Adrian Cole commented on WHIRR-410:
-----------------------------------
well, we'd have to isolate the issue wrt the 32bit OS dist. This isn't the
first ubuntu dist that's had ssh connectivity issues (ex. the first Natty
cluster compute one did as well). clearly there's something screwy on that
image, and it is possibly worth isolating (whether it is getting a copy of sshd
logs, etc.). What makes it worth it is that screwy images do exist, and the
time to repair the configuration is likely less than time spent troubleshooting
this every so often, then saying use another image.
That said, I think the jclouds templateBuilder can be a bit smarter wrt 64bit.
Currently, it doesn't sort on 64bit unless you've explicitly specified. So,
instead, the image is sorting lexicographically. Since amd64 is before i386,
we end up prefering 32bit amis (at least those with this naming convention).
This isn't ideal. I suspect this was in place to ensure that m1.small can be
selected by default, as it is a 32 bit machine. However, it is no longer the
cheapest, and only in aws-ec2 is m1.small 32bit (ex. in eucalyptus, etc. it is
64bit). Thoughts are that we could try changing jclouds TemplateBuilderImpl to
prefer 64bit (squishily), just that we should make sure it doesn't artificially
fail when only a 32bit image is available. This can be tested by playing with
"stub" computeService so that it only has 32 bit images and see if the
expressions hold. (ex. StubComputeServiceAdapter line 131)
> Review automatic image selection
> --------------------------------
>
> Key: WHIRR-410
> URL: https://issues.apache.org/jira/browse/WHIRR-410
> Project: Whirr
> Issue Type: Bug
> Reporter: Andrei Savu
> Fix For: 0.7.0
>
> Attachments: WHIRR-410.patch
>
>
> While I was testing WHIRR-400 I have noticed that the ZooKeeper integration
> tests are failing on aws-ec2 with the automatically selected AMI but they are
> working as expected with the Amazon Linux AMI. The tests are also working as
> expected on cloudservers-us. This makes me think the failure is not related
> to our code changes and we should look for an external factor as the root
> cause.
> As part of this issue we should think about how to improve the automatic AMI
> selection mechanism in order to make it more robust and less likely to fail
> due to AMI upgrades and other external changes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
