https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1304407
It should be fixed in 1.18.3.
John
=:->
On Mon, May 12, 2014 at 9:36 PM, Henning Eggers wrote:
> Hi!
>
> I just noticed that I now have specify the arch constraint if I want amd64
> instances. Without it, I get i386 instances. "
However, the fix is slightly different than just "always choose amd64".
Instead, we always choose the same architecture as the client machine,
that way if the user uses --upload-tools, the tools will actually work on
the cloud machine.
This means that if you're running i386, you would still need
Why isn't the default tweaked by --upload-tools itself then? We
should be optimizing these options for users, rather than for
developers, and it sounds sensible to assume that the vast majority of
users do want to deploy on amd64 rather than i386 or arm.
On Mon, May 12, 2014 at 2:53 PM, Nate Finc
Ah, thank you! I searched for a matching bug but I guess I used the wrong
search terms. ;-)
Cheers,
Henning
Am 12.05.2014 19:50, schrieb John Meinel:
> https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1304407
>
> It should be fixed in 1.18.3.
> John
> =:->
>
>
>
> On Mon, May 12, 2014 at
Although I don't know about --upload-tools, I have to agree with Gustavo here
that selecting the instance arch depending on the workstation arch is
unintuitive from a user's perspective. I would not expect that at all.
Yes, amd64 is a very sensible default. I would wish that it stayed that way.
H
Strongly agree with gustavo/henning. In *all* cases, the possibilities are
defined by the arches of the available tools, images, and instance types.
When using --upload-tools, the arches of the available tools are further
restricted, and may thus force i386, but that should have no impact
whatsoeve
(for pedantry's sake: constraints are not really the issue here. They're
just a mechanism for filtering the acceptable set of results for a
provisioning decision; and they handy from a dev perspective in that they
allow us also to filter the inputs and cut down on the range of
possibilities we have
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 whil
FWIW, I think the byArch did a plain sort.Strings() which happens to pick
amd64 because it is before all other in a typographical fashion. IIRC, it
may have mutated a lot over time because the sorting was blocking bootstrap
from working on ppc64 which was why it was removed. Also, on MaaS, MaaS
doe
On Tue, May 13, 2014 at 8:18 AM, John Meinel 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 i3
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
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 *multipl
On Wed, May 14, 2014 at 4:28 AM, William Reade
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 constraint
13 matches
Mail list logo
