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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
