defaulting to arch of local machine

[John Meinel]

I think prefering amd64 over i386 is reasonable.  I know, though, that we
had at least one person on an i386 that thought --upload-tools would work.
The fact that we have upload-tools is a strong hint to prefer
version.Current.Arch.
Also, we used to fix it to amd64 but that broke for clouds that are all
arm64 or ppc64. Which is why it just picks one that it can.
I have the feeling it is map ordering, because I've had both i386 and amd64
picked by default.

John
=:->
On Apr 18, 2014 11:07 PM, "Nate Finch" <nate.finch at canonical.com> wrote:

> We have a bug where Juju is no longer defaulting to the arch of the local
> machine, but instead always choosing 386.
>
> Bug #1304407: juju bootstrap defaults to i386 <amd64> <apport-bug>
> <ec2-images> <metadata> <trusty> <juju-core:Triaged> <juju-core
> 1.18:Triaged> <juju-core (Ubuntu):Triaged>
> https://launchpad.net/bugs/1304407
>
> I'm not exactly sure how this worked in the past.  From what I can tell,
> if you don't specifically give an arch constraint, the code just picks
> whatever the first image is that matches your other constraints (which may
> or may not be the same arch as your local machine).  My guess is that the
> order of the images coming from EC2 recently changed so 386 was first,
> where before it was amd64.... and we just never noticed before that we
> always chose amd64, because that's generally what we all run locally anyway.
>
> Fixing the bug is trivial, I can just prefer the one that matches the
> local arch... but it makes me wonder, is that really the best default?
>
> Wouldn't it be better to simply always default to amd64 unless such an
> image doesn't exist, or the user explicitly asks for 386?  amd64 is almost
> always going to be a better choice, it's the implicit default for
> everything these days, and personally, I would find it surprisingly
> inconsistent that juju would deploy different images to the cloud if I ran
> it on my old 386 laptop than on my new amd64 laptop.
>
> But there may be a reason for this choice that I'm not aware of, so feel
> free to let me know in that case.
>
> -Nate
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140419/2cee39c9/attachment.html>