arch constraint default changed?

Andrew Wilkins andrew.wilkins at canonical.com
Fri May 16 08:55:56 UTC 2014


On Wed, May 14, 2014 at 4:28 AM, William Reade
<william.reade at 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.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
>>
>>
>
> --
> 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/20140516/6829ad2f/attachment.html>


More information about the Juju mailing list