Re: arch constraint default changed?
On Wed, May 14, 2014 at 4:28 AM, William Reade william.re...@canonical.comwrote: 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.fi...@canonical.comwrote: 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.netwrote: 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 -- Juju mailing list
Re: arch constraint default changed?
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. Henning Am 12.05.2014 19:58, schrieb Gustavo Niemeyer: 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 Finch nate.fi...@canonical.com wrote: 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 --arch amd64 to get amd64 machines in the cloud. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: arch constraint default changed?
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 whatsoever on our method for choosing amongst the available options. I remember writing a byArch sort that prioritised amd64; it seems to have disappeared at some point in the last year, as the tools/instance-types/etc code evolved, but this was always intended behaviour; please reinstate it. On Tue, May 13, 2014 at 9:15 AM, Henning Eggers henn...@keeeb.com wrote: 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. Henning Am 12.05.2014 19:58, schrieb Gustavo Niemeyer: 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 Finch nate.fi...@canonical.com wrote: 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 --arch amd64 to get amd64 machines in the cloud. -- 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
Re: arch constraint default changed?
(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 to choose from; but there is no default arch constraint, other than I don't care.) On Tue, May 13, 2014 at 10:33 AM, William Reade william.re...@canonical.com wrote: 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 whatsoever on our method for choosing amongst the available options. I remember writing a byArch sort that prioritised amd64; it seems to have disappeared at some point in the last year, as the tools/instance-types/etc code evolved, but this was always intended behaviour; please reinstate it. On Tue, May 13, 2014 at 9:15 AM, Henning Eggers henn...@keeeb.com wrote: 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. Henning Am 12.05.2014 19:58, schrieb Gustavo Niemeyer: 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 Finch nate.fi...@canonical.com wrote: 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 --arch amd64 to get amd64 machines in the cloud. -- 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
Re: arch constraint default changed?
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. 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? 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.) John =:- On Tue, May 13, 2014 at 12:39 PM, William Reade william.re...@canonical.com wrote: (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 to choose from; but there is no default arch constraint, other than I don't care.) On Tue, May 13, 2014 at 10:33 AM, William Reade william.re...@canonical.com wrote: 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 whatsoever on our method for choosing amongst the available options. I remember writing a byArch sort that prioritised amd64; it seems to have disappeared at some point in the last year, as the tools/instance-types/etc code evolved, but this was always intended behaviour; please reinstate it. On Tue, May 13, 2014 at 9:15 AM, Henning Eggers henn...@keeeb.comwrote: 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. Henning Am 12.05.2014 19:58, schrieb Gustavo Niemeyer: 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 Finch nate.fi...@canonical.com wrote: 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 --arch amd64 to get amd64 machines in the cloud. -- 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
Re: arch constraint default changed?
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 doesn't seem to actually be giving us what arches are available, which is why every bootstrap gives a warning about picking arbitrary tools, and we have an open bug that just juju bootstrap on an all-ppc64 MaaS doesn't work, you are required to specify the arch=ppc64 for it to work there. John =:- On Tue, May 13, 2014 at 12:33 PM, William Reade william.re...@canonical.com wrote: 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 whatsoever on our method for choosing amongst the available options. I remember writing a byArch sort that prioritised amd64; it seems to have disappeared at some point in the last year, as the tools/instance-types/etc code evolved, but this was always intended behaviour; please reinstate it. On Tue, May 13, 2014 at 9:15 AM, Henning Eggers henn...@keeeb.com wrote: 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. Henning Am 12.05.2014 19:58, schrieb Gustavo Niemeyer: 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 Finch nate.fi...@canonical.com wrote: 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 --arch amd64 to get amd64 machines in the cloud. -- 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
Re: arch constraint default changed?
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.netwrote: 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
Re: arch constraint default changed?
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.comwrote: 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.netwrote: 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
arch constraint default changed?
Hi! I just noticed that I now have specify the arch constraint if I want amd64 instances. Without it, I get i386 instances. juju help constraints still tells me that amd64 is supposed to be the default. I am using juju 1.18.2 on EC2, precise on the instances, trusty on my workstation. Has this since been fixed? Or is it an intentional change and the help page is outdated? Cheers, Henning -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: arch constraint default changed?
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 henn...@keeeb.com wrote: Hi! I just noticed that I now have specify the arch constraint if I want amd64 instances. Without it, I get i386 instances. juju help constraints still tells me that amd64 is supposed to be the default. I am using juju 1.18.2 on EC2, precise on the instances, trusty on my workstation. Has this since been fixed? Or is it an intentional change and the help page is outdated? Cheers, Henning -- 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
Re: arch constraint default changed?
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 Finch nate.fi...@canonical.com wrote: 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 --arch amd64 to get amd64 machines in the cloud. On Mon, May 12, 2014 at 1:50 PM, John Meinel j...@arbash-meinel.com wrote: 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 henn...@keeeb.com wrote: Hi! I just noticed that I now have specify the arch constraint if I want amd64 instances. Without it, I get i386 instances. juju help constraints still tells me that amd64 is supposed to be the default. I am using juju 1.18.2 on EC2, precise on the instances, trusty on my workstation. Has this since been fixed? Or is it an intentional change and the help page is outdated? Cheers, Henning -- 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 -- gustavo @ http://niemeyer.net -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: arch constraint default changed?
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 9:36 PM, Henning Eggers henn...@keeeb.com mailto:henn...@keeeb.com wrote: Hi! I just noticed that I now have specify the arch constraint if I want amd64 instances. Without it, I get i386 instances. juju help constraints still tells me that amd64 is supposed to be the default. I am using juju 1.18.2 on EC2, precise on the instances, trusty on my workstation. Has this since been fixed? Or is it an intentional change and the help page is outdated? Cheers, Henning -- Juju mailing list Juju@lists.ubuntu.com mailto: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
