arch constraint default changed?

[Nate Finch]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140513/265fcdbb/attachment.html>