Right now, the default tabular output is behind a feature flag because it's
experimental. We still need to decide how to allow users to have that output by
default without the feature flag, but also without breaking 1.18 script
compatibility. The best option IMO for this case is an env variable on
On 30 April 2015 at 11:55, Ian Booth ian.bo...@canonical.com wrote:
Right now, the default tabular output is behind a feature flag because it's
experimental. We still need to decide how to allow users to have that output
by
default without the feature flag, but also without breaking 1.18
I would say the exact opposite. We *cannot* sacrifice the usability and
reliability of the product for all our future users just to keep a few
current users from having to update their scripts ever.
I am sure there will come a day when we decide that there is a change that
makes the client
I don't want to bore on and on about this, but one thing.
On 30 April 2015 at 22:06, Nate Finch nate.fi...@canonical.com wrote:
If someone needs 1.18 CLI compatibility, they can use 1.18. It's that
simple.
It's not that simple to do that though, as long as new versions of
juju go into
At the Nuremberg sprint, I saw a demo of juju status that produced
tabular format
by default. I'm guessing that this issue means that can never actually be
enabled.
Although... it could be done backwardly compatibly (with a required environment
variable or configuration file setting) and perhaps
On 30/04/15 21:04, roger peppe wrote:
On 30 April 2015 at 11:55, Ian Booth ian.bo...@canonical.com wrote:
Right now, the default tabular output is behind a feature flag because it's
experimental. We still need to decide how to allow users to have that output
by
default without the feature
On Thu, 30 Apr 2015, Nate Finch wrote:
If someone needs 1.18 CLI compatibility, they can use 1.18. It's that
simple. We're maintaining API compatibility for just this reason. If they
don't want the binary to change, they shouldn't update it (or should just
rename it to juju-1.18 or
On 28 April 2015 at 19:41, Nate Finch nate.fi...@canonical.com wrote:
No one seems to be answering my actual question. That error message seems
new. Is it? Either way, the error message is incorrect - control bucket is
not required - and whatever is emitting that message needs to be fixed.
On 28 April 2015 at 19:32, Aaron Bentley aaron.bent...@canonical.com wrote:
On 2015-04-28 11:42 AM, roger peppe wrote:
The .jenv code was introduced prior to 1.16. How far back in time
do we need to preserve compatibility? (genuine question)
We need to support every mode of operation that
On 29 April 2015 at 01:05, Jesse Meek jesse.m...@canonical.com wrote:
Hi Nate,
I looked into your bug. The default value for control-bucket was not being
set. Here's a PR to fix: http://reviews.vapour.ws/r/1512/
I'm not entirely sure that's the right fix. The original error message
was right
On 29 April 2015 at 17:10, Aaron Bentley aaron.bent...@canonical.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-04-29 10:43 AM, roger peppe wrote:
Once Trusty EOLs, then I think we would be able to drop
functionality that 1.18 itself used only for migration.
For example,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-04-29 10:43 AM, roger peppe wrote:
Once Trusty EOLs, then I think we would be able to drop
functionality that 1.18 itself used only for migration.
For example, if juju 1.18 had automatically created .jenvs from
the environments.yaml
We have done it before. As Roger said, there is/was a convention to do a
three step process to deprecate old command line functionality.
There's a big difference between what the command line looks like, and
keeping compatibility with 1.18. We might want to preserve both, but
they're not the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-04-29 12:31 PM, roger peppe wrote:
FWIW I seem to remember some command line flags being deprecated
(with a visible warning message) and then removed. I wonder if that
might be another possible approach that could let us avoid
unbounded
On 30 April 2015 at 07:40, Nate Finch nate.fi...@canonical.com wrote:
We have done it before. As Roger said, there is/was a convention to do a
three step process to deprecate old command line functionality.
There's a big difference between what the command line looks like, and
keeping
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-04-29 04:10 AM, roger peppe wrote:
On 28 April 2015 at 19:32, Aaron Bentley
aaron.bent...@canonical.com wrote:
On 2015-04-28 11:42 AM, roger peppe wrote:
The .jenv code was introduced prior to 1.16. How far back in
time do we need to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-04-29 09:41 AM, Nate Finch wrote:
I think you're missing roger's point.
No, I understand his point, and I think that his extrapolation is
incorrect, and I explained how.
1.18 has some fallback code to support 1.16. However, we don't
On 29 April 2015 at 14:34, Aaron Bentley aaron.bent...@canonical.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-04-29 04:10 AM, roger peppe wrote:
On 28 April 2015 at 19:32, Aaron Bentley
aaron.bent...@canonical.com wrote:
On 2015-04-28 11:42 AM, roger peppe wrote:
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-04-27 05:30 PM, roger peppe wrote:
That fallback code was designed to be around for only a short time
- I'd suggest removing it.
We have bugs about the fact that the fallback code has been removed:
Hi Nate,
I looked into your bug. The default value for control-bucket was not
being set. Here's a PR to fix: http://reviews.vapour.ws/r/1512/
Cheers,
Jess
On 29/04/15 06:41, Nate Finch wrote:
No one seems to be answering my actual question. That error message
seems new. Is it? Either
On 29/04/15 04:41, Nate Finch wrote:
No one seems to be answering my actual question. That error message seems
new. Is it? Either way, the error message is incorrect - control bucket is
not required - and whatever is emitting that message needs to be fixed.
On Apr 28, 2015 2:32 PM, Aaron
I mean, the control-bucket configuration value in the ec2 section of your
environments.yaml is not required, and thus the error message is incorrect.
On Tue, Apr 28, 2015 at 10:26 PM, Ian Booth ian.bo...@canonical.com wrote:
On 29/04/15 04:41, Nate Finch wrote:
No one seems to be answering
The .jenv code was introduced prior to 1.16. How far back
in time do we need to preserve compatibility? (genuine
question)
If transitioning to the new scheme is really an issue, it
would be easy to write a very simple tool that would
allow a .jenv file to be created from an existing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-04-28 11:42 AM, roger peppe wrote:
The .jenv code was introduced prior to 1.16. How far back in time
do we need to preserve compatibility? (genuine question)
We need to support every mode of operation that 1.18 supported. Juju
has a
No one seems to be answering my actual question. That error message seems
new. Is it? Either way, the error message is incorrect - control bucket is
not required - and whatever is emitting that message needs to be fixed.
On Apr 28, 2015 2:32 PM, Aaron Bentley aaron.bent...@canonical.com
wrote:
If I do juju status with an unbootstrapped amazon environment, I get this:
/home/nate/src/github.com/juju/juju master$ juju status
ERROR Unable to connect to environment amazon.
Please check your credentials or use 'juju bootstrap' to create a new
environment.
Error details:
invalid EC2 provider
26 matches
Mail list logo
