FWIW, I've gotten bug requests from a user that did a regular bootstrap and then was trying to "juju upgrade-juju --upload-tools" and was confused that his local machine wasn't able to upgrade tools for his environment. (he was running i386 locally, and bootstrap created an amd64 machine). And while we desperately want to not expose --upload-tools in its current incarnation, we haven't given an alternative for those use cases.
Also, while we have a reasonably clear model for "if you have the choice between amd64 and i386 pick amd64", I don't think people disagree with that. But what if you have the choice between amd64 and ppc64le and the client is running on ppc64le? Is it likely that they are actually thinking in a ppc world? We certainly had a lot of discussions around this between Nate and myself, and while I think I was reasonably convinced that we could just pick amd64 if it was an option, it seems he was also reasonably convinced that we'd want to use the client arch if available. (He wrote it as "just pick amd64", I argued against it but ended up feeling it was a reasonable pick among alternatives, but then he changed it before landing.) John =:-> On Tue, May 13, 2014 at 12:39 PM, William Reade <william.re...@canonical.com > wrote: > (for pedantry's sake: constraints are not really the issue here. They're > just a mechanism for filtering the acceptable set of results for a > provisioning decision; and they handy from a dev perspective in that they > allow us also to filter the inputs and cut down on the range of > possibilities we have to choose from; but there is no "default" arch > constraint, other than "I don't care".) > > > On Tue, May 13, 2014 at 10:33 AM, William Reade < > william.re...@canonical.com> wrote: > >> Strongly agree with gustavo/henning. In *all* cases, the possibilities >> are defined by the arches of the available tools, images, and instance >> types. When using --upload-tools, the arches of the available tools are >> further restricted, and may thus force i386, but that should have no impact >> whatsoever on our method for choosing amongst the available options. >> >> I remember writing a byArch sort that prioritised amd64; it seems to have >> disappeared at some point in the last year, as the tools/instance-types/etc >> code evolved, but this was always intended behaviour; please reinstate it. >> >> >> On Tue, May 13, 2014 at 9:15 AM, Henning Eggers <henn...@keeeb.com>wrote: >> >>> Although I don't know about --upload-tools, I have to agree with Gustavo >>> here >>> that selecting the instance arch depending on the workstation arch is >>> unintuitive from a user's perspective. I would not expect that at all. >>> >>> Yes, amd64 is a very sensible default. I would wish that it stayed that >>> way. >>> >>> Henning >>> >>> Am 12.05.2014 19:58, schrieb Gustavo Niemeyer: >>> > Why isn't the default tweaked by --upload-tools itself then? We >>> > should be optimizing these options for users, rather than for >>> > developers, and it sounds sensible to assume that the vast majority of >>> > users do want to deploy on amd64 rather than i386 or arm. >>> > >>> > On Mon, May 12, 2014 at 2:53 PM, Nate Finch <nate.fi...@canonical.com> >>> wrote: >>> >> However, the fix is slightly different than just "always choose >>> amd64". >>> >> Instead, we always choose the same architecture as the client >>> machine, that >>> >> way if the user uses --upload-tools, the tools will actually work on >>> the >>> >> cloud machine. >>> >> >>> >> This means that if you're running i386, you would still need --arch >>> amd64 to >>> >> get amd64 machines in the cloud. >>> >> >>> >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >> >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
