On Wed, May 14, 2014 at 4:28 AM, William Reade <william.re...@canonical.com>wrote:
> We shouldn't ever have to worry about whether or not --upload-tools was > used, because it's *already* been used at the point where we pick > instances, and the single possible arch is thus already chosen, entirely > independent of constraints or anything else. The only question should be: > given *multiple* possible architectures to launch, with nothing else to > decide between them, which do we pick? > > The original algorithm was "amd64 if available; if not, first > alphabetical". I still think that'd be better than what we have, but as our > options expand I think I'd prefer to go with "first alphabetical 64-bit > arch, falling back to first alphabetical". Dissent? > I am working on implementing this algorithm as a part of fixing https://bugs.launchpad.net/juju-core/+bug/1262967 Cheers > William > > > On Tue, May 13, 2014 at 3:59 PM, Nate Finch <nate.fi...@canonical.com>wrote: > >> For what it's worth, I agree with everyone. John and I discussed it, and >> I thought we had decided that we needed to use the local arch because of >> upload tools, evidently John though we'd decided in the other direction. >> And Gustavo is right that we should have pushed the discussion to the >> mailing list regardless. >> >> I didn't want the local arch have any influence on the arch we pick, >> unless the user uses --upload-tools, because as Gustavo said, where I'm >> sitting right now shouldn't affect what architecture my cloud uses. >> >> Honestly, the reason I didn't code the fix to take --upload-tools into >> consideration is because that was going to be more complicated and I didn't >> have time for it (the fix I made was tiny and quick). Perhaps that was a >> misjudgment, and perhaps if we had moved the question to the mailing list >> it would have become obvious the time would be worth it. >> >> If people think it's worth it, we can just go ahead and make the right >> fix to use the local arch only when we use --upload-tools, but it still >> doesn't help us with the problem of which one we pick if they don't use >> upload tools, and multiple arches are available. What logic would people >> recommend? I don't think alphabetical is really the best choice, though at >> least it's deterministic, unlike "take whatever happens to be listed first" >> which is what we seemed to be doing before. >> >> >> On Tue, May 13, 2014 at 8:17 AM, Gustavo Niemeyer >> <gust...@niemeyer.net>wrote: >> >>> On Tue, May 13, 2014 at 8:18 AM, John Meinel <j...@arbash-meinel.com> >>> wrote: >>> > 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. >>> >>> There's nothing wrong with tweaking constraints if the application >>> sees the --upload-tools option. At the same time, getting a bug from a >>> user is not enough reason to tweak the defaults for everybody. >>> >>> > 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? >>> >>> I don't see how that logic holds. Using an arm laptop as a client does >>> not imply I want to use all my server deployments on arm. The same >>> holds true for the operating system, or to the Ubuntu series, or to >>> pretty much anything else: I would not expect the tool to deploy a >>> completely different environment based on where I'm sitting this >>> second. >>> >>> > 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.) >>> >>> If I had the chance, I would submit these kinds of decisions to the >>> development mailing list, rather than arbitrating it back and forth in >>> isolation like that. This is changing the default behavior for >>> everybody, so sending it for the team's appraisal feels cheap. >>> >>> >>> gustavo @ http://niemeyer.net >>> >>> -- >>> 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 > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju