arch constraint default changed?

[William Reade]

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.finch at 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 <gustavo at niemeyer.net>wrote:
>
>> On Tue, May 13, 2014 at 8:18 AM, John Meinel <john at 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 at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140513/a94aa883/attachment.html>