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? 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