Re: $ juju switch --format
On 9 June 2014 21:57, Tim Penhey tim.pen...@canonical.com wrote: OK, this has gone WAY beyond any reasonable work for this work item. Total agreement. I intended my remarks as more a future-looking where are we aiming for? than we should do this now. For current work, I think that: a) the juju switch command is just fine as it is now. b) we could use a juju info (or similarly named) command that shows information on the currently selected environment, including user name, UUID, etc. Both of these should be forwardly compatible with all my suggestions. I agree that we may well want to change how we store things on disk, but I won't be doing that for this work. If we are going to do this, and I can see some benefits of doing it, it needs to be spec'ed out as an independent piece of work. Let's do this. It interacts with some of the stuff I am working on, hence my interest here. cheers, rog. Tim On 09/06/14 22:07, roger peppe wrote: On 6 June 2014 14:20, William Reade william.re...@canonical.com wrote: Thanks for these very useful and constructive remarks. I now understand better where the original proposal was coming from. On Fri, Jun 6, 2014 at 11:34 AM, roger peppe rogpe...@gmail.com wrote: On 5 June 2014 23:16, Tim Penhey tim.pen...@canonical.com wrote: Addressing the concerns, can we not: $ juju switch [env] $ juju info # display env info of env user just switched into OK, here is my proposal, which I hope addresses all the concerns and gives us a way forwards. This looks like a great direction, thanks. 1) juju switch with no args becomes deprecated (replaced by juju info) and will be removed one release following, continues to work as before 2) juju switch --list becomes deprecated (replaced by juju info) 3) juju switch new-env --format=[json,yaml] will output new information, but just environment name, old env name and username I'm not sure this is a win. At the moment, switch is actually pretty cohesive: it's the command that deals with setting the user/environment that will apply to future commands; it provides a way to get information about the current user/environment; and it lists the available choices for the active form. This proposal splits away a seemingly arbitrary subset of the user/environment information -- parts of which are actually necessary to distinguish between environments in only-mildly-pathological cases (eg, `tim in prod` is not enough information to unambiguously specify where you've actually switched to) -- and puts it behind a separate command; I'm not convinced that your experience of a clear separation between switch and env is a general one. It's true that tim in prod isn't enough information to unambiguously specifiy where you've actually switched to, but I wonder if that actually matters. If we treat environment names as local aliases for global entities, then each user can be under total control of their local names, and thus can know what environment a given name refers to because they chose it - it's their chosen nickname for the environment, so from a *user's* point of view, it could be considered unambiguous. Part of my issue with putting user information into switch was that I was looking at our current state of affairs, where an environment name unambiguously specifies an environment and a user-creds pair. The main thrust of my suggestion was that we (1) accept that switch, when switching, needs to output more information when switching so that you can tell where you've switched to; and (2) make sure we integrate the change fully, such that switch's other modes also output what the user actually needs to be aware of, while preserving but deprecating the original behaviour for one release. Part of doing this right is implementing the --format flag for the result data; and the shared implementation for the --format flag lets you specify a default that lets you mangle a given object into a list of bytes however you desire. By implementing an output formatter that takes the common in-memory result format and expresses the original output format of that data -- flawed and incomplete though that format may be -- we get to use a single mechanism across the board and perfectly encapsulate the old output format such that removing or changing it becomes literally trivial. I don't see why the username creeps in here. As I understand it, switch is just about switching environments. If we keep it that way, I think it makes coherent sense as a command if we have these possible usages of it: environment is an inadequate concept. You're almost always *some user in* some environment. We can't hide it, we have to expose it, but it's potentially confusing so we need to do it tastefully. Yes. juju switch environment-name switches to the environment with the given name. You have two jenvs for the same environment named prod, as users admin and roger (roger has
Re: $ juju switch --format
On 6 June 2014 14:20, William Reade william.re...@canonical.com wrote: Thanks for these very useful and constructive remarks. I now understand better where the original proposal was coming from. On Fri, Jun 6, 2014 at 11:34 AM, roger peppe rogpe...@gmail.com wrote: On 5 June 2014 23:16, Tim Penhey tim.pen...@canonical.com wrote: Addressing the concerns, can we not: $ juju switch [env] $ juju info # display env info of env user just switched into OK, here is my proposal, which I hope addresses all the concerns and gives us a way forwards. This looks like a great direction, thanks. 1) juju switch with no args becomes deprecated (replaced by juju info) and will be removed one release following, continues to work as before 2) juju switch --list becomes deprecated (replaced by juju info) 3) juju switch new-env --format=[json,yaml] will output new information, but just environment name, old env name and username I'm not sure this is a win. At the moment, switch is actually pretty cohesive: it's the command that deals with setting the user/environment that will apply to future commands; it provides a way to get information about the current user/environment; and it lists the available choices for the active form. This proposal splits away a seemingly arbitrary subset of the user/environment information -- parts of which are actually necessary to distinguish between environments in only-mildly-pathological cases (eg, `tim in prod` is not enough information to unambiguously specify where you've actually switched to) -- and puts it behind a separate command; I'm not convinced that your experience of a clear separation between switch and env is a general one. It's true that tim in prod isn't enough information to unambiguously specifiy where you've actually switched to, but I wonder if that actually matters. If we treat environment names as local aliases for global entities, then each user can be under total control of their local names, and thus can know what environment a given name refers to because they chose it - it's their chosen nickname for the environment, so from a *user's* point of view, it could be considered unambiguous. Part of my issue with putting user information into switch was that I was looking at our current state of affairs, where an environment name unambiguously specifies an environment and a user-creds pair. The main thrust of my suggestion was that we (1) accept that switch, when switching, needs to output more information when switching so that you can tell where you've switched to; and (2) make sure we integrate the change fully, such that switch's other modes also output what the user actually needs to be aware of, while preserving but deprecating the original behaviour for one release. Part of doing this right is implementing the --format flag for the result data; and the shared implementation for the --format flag lets you specify a default that lets you mangle a given object into a list of bytes however you desire. By implementing an output formatter that takes the common in-memory result format and expresses the original output format of that data -- flawed and incomplete though that format may be -- we get to use a single mechanism across the board and perfectly encapsulate the old output format such that removing or changing it becomes literally trivial. I don't see why the username creeps in here. As I understand it, switch is just about switching environments. If we keep it that way, I think it makes coherent sense as a command if we have these possible usages of it: environment is an inadequate concept. You're almost always *some user in* some environment. We can't hide it, we have to expose it, but it's potentially confusing so we need to do it tastefully. Yes. juju switch environment-name switches to the environment with the given name. You have two jenvs for the same environment named prod, as users admin and roger (roger has fewer permissions). (Or, equivalently, your identity on your state server gives you access to those users in those environments.) Similarly, in the same way, you have access to another environment, created by me and also named prod, in which you also have the username roger. What does `juju switch prod` do? Even with, say, `juju switch roger@prod`, there's scope for ambiguity and hence bad experiences. I think that you have to allow aliases for user/environment pairs, and have `juju switch` use those aliases to control both user-switching and environment-switching. If you can come up with an alternative that cleanly separates the concepts I will be most interested. How about something like this? We split the current .jenv file into two - one part holding the CA cert and the API endpoint (and potentially the bootstrap config too). We also add a level of indirection between the environment name and the UUID. We store the following data (where [x]
Re: $ juju switch --format
OK, this has gone WAY beyond any reasonable work for this work item. I agree that we may well want to change how we store things on disk, but I won't be doing that for this work. If we are going to do this, and I can see some benefits of doing it, it needs to be spec'ed out as an independent piece of work. Tim On 09/06/14 22:07, roger peppe wrote: On 6 June 2014 14:20, William Reade william.re...@canonical.com wrote: Thanks for these very useful and constructive remarks. I now understand better where the original proposal was coming from. On Fri, Jun 6, 2014 at 11:34 AM, roger peppe rogpe...@gmail.com wrote: On 5 June 2014 23:16, Tim Penhey tim.pen...@canonical.com wrote: Addressing the concerns, can we not: $ juju switch [env] $ juju info # display env info of env user just switched into OK, here is my proposal, which I hope addresses all the concerns and gives us a way forwards. This looks like a great direction, thanks. 1) juju switch with no args becomes deprecated (replaced by juju info) and will be removed one release following, continues to work as before 2) juju switch --list becomes deprecated (replaced by juju info) 3) juju switch new-env --format=[json,yaml] will output new information, but just environment name, old env name and username I'm not sure this is a win. At the moment, switch is actually pretty cohesive: it's the command that deals with setting the user/environment that will apply to future commands; it provides a way to get information about the current user/environment; and it lists the available choices for the active form. This proposal splits away a seemingly arbitrary subset of the user/environment information -- parts of which are actually necessary to distinguish between environments in only-mildly-pathological cases (eg, `tim in prod` is not enough information to unambiguously specify where you've actually switched to) -- and puts it behind a separate command; I'm not convinced that your experience of a clear separation between switch and env is a general one. It's true that tim in prod isn't enough information to unambiguously specifiy where you've actually switched to, but I wonder if that actually matters. If we treat environment names as local aliases for global entities, then each user can be under total control of their local names, and thus can know what environment a given name refers to because they chose it - it's their chosen nickname for the environment, so from a *user's* point of view, it could be considered unambiguous. Part of my issue with putting user information into switch was that I was looking at our current state of affairs, where an environment name unambiguously specifies an environment and a user-creds pair. The main thrust of my suggestion was that we (1) accept that switch, when switching, needs to output more information when switching so that you can tell where you've switched to; and (2) make sure we integrate the change fully, such that switch's other modes also output what the user actually needs to be aware of, while preserving but deprecating the original behaviour for one release. Part of doing this right is implementing the --format flag for the result data; and the shared implementation for the --format flag lets you specify a default that lets you mangle a given object into a list of bytes however you desire. By implementing an output formatter that takes the common in-memory result format and expresses the original output format of that data -- flawed and incomplete though that format may be -- we get to use a single mechanism across the board and perfectly encapsulate the old output format such that removing or changing it becomes literally trivial. I don't see why the username creeps in here. As I understand it, switch is just about switching environments. If we keep it that way, I think it makes coherent sense as a command if we have these possible usages of it: environment is an inadequate concept. You're almost always *some user in* some environment. We can't hide it, we have to expose it, but it's potentially confusing so we need to do it tastefully. Yes. juju switch environment-name switches to the environment with the given name. You have two jenvs for the same environment named prod, as users admin and roger (roger has fewer permissions). (Or, equivalently, your identity on your state server gives you access to those users in those environments.) Similarly, in the same way, you have access to another environment, created by me and also named prod, in which you also have the username roger. What does `juju switch prod` do? Even with, say, `juju switch roger@prod`, there's scope for ambiguity and hence bad experiences. I think that you have to allow aliases for user/environment pairs, and have `juju switch` use those aliases to control both user-switching and environment-switching. If you can come up with an
Re: $ juju switch --format
I think where people are getting confused is the relationship between the various uses of the name environment. We have more a language problem. We currently use environment to mean several things: 1) a running environment that has many users 2) an entry in the environments.yaml file 3) the name of a .jenv file in $JUJU_HOME/environments You can quickly see where the confusion comes from. In all cases where we are talking about environments from the command line, what we are really talking about are environment/user pairs, and that this pair is given a name, or alias that the user uses to refer to that pair. When the environment (the first meaning) is running, the user has a name for it that is used for the .jenv file. That file encapsulates the identity of the running environment (through the uuid and also the api endpoints). When the environment (again the first meaning) isn't running, then it only relates to the entry in the environments.yaml file (which as I understand it, we want to get rid of eventually). The main thrust of the proposal is to do the following: * juju switch has one and only one task, and that is to change between user-aliases for environment/user pairs, and when the change is made, it tells you that environment and user you are now using (and maybe status[1]) * juju info tells us information about our environments. It does not do remote calls to any environment, just gives a more friendly way to query what .jenv files we have and what environments we have defined in the environments.yaml file - yes we could have a 'juju info --name-only' or some other flag to support the use case where people really do want to destroy their current environment with out specifying exactly :-) Tim [1] status is inferred from the source: if using a jenv file, we assume it is running, if from the environments.yaml it is not running, and we look for the .jenv file first. I'd be happy to call this something other than status -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: $ juju switch --format
Ha, that's cute. Honestly, that's still difficult enough to type that I can't see people typing that every time by hand. Generally you *know* what environment you want to destroy anyway, and whatever name you picked has to be easier than typing $(juju env). But it's a useful tip for scripts. There's basically no way to totally prevent people from shooting themselves in the foot if they work at it... but we can at least start them with the barrel of the gun pointing downrange. On Sat, Jun 7, 2014 at 12:13 AM, John Meinel j...@arbash-meinel.com wrote: ... Do the following use cases express your needs (even if you weren't hitherto aware that you were specifically manipulating environment *connections*)? Ah, ok, things are changing, got it. Making sure patterns like the following are still easily grok-able (even if it's a different command) is nice: juju destroy-environment $(juju env) Juju env used to print a lot of decoration around the environment name, As a side note, I love how the explicit request to us was juju destroy environment is too easy to destroy the wrong thing, can you please make it so that you have to type the explicit name so we know we are destroying the right thing, and people quickly figured out how to write a command that destroys whatever the current environment is to workaround the exact syntax we put in place to protect it. Nothing to do with you specifically, just that people's use cases are different. I certainly hope we never document juju destroy-environment $(juju env) as a recommended thing. But it does signal that some people really don't want the extra safety measures and would much rather have a clean way of disabling them. John =:- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: $ juju switch --format
I like Rog's suggestions about switch being all about environment names, and nothing else, and juju env being about only printing local info about an environment. Keeping it away from the network is a good thing. If they want status, they can run status. On Fri, Jun 6, 2014 at 5:34 AM, roger peppe rogpe...@gmail.com wrote: On 5 June 2014 23:16, Tim Penhey tim.pen...@canonical.com wrote: On 06/06/14 09:55, Jesse Meek wrote: I have a branch proposed that displays extra environment information when the --format flag is used with switch e.g: $ juju switch local --format yaml environ-name: local previous-environ-name: ec2 state-servers: - example.com - kremvax.ru username: joe There is some debate over this. Roger has summarised the key issues well in his review comment: I think this is a bit odd. In every other command AFAIK, choosing a format does not affect the actual information displayed, just the format that it's printed in. Why are we printing all this info with the switch command anyway? Personally I'd think that a new command was warranted here, perhaps juju current, or juju show or juju info. I was going to comment on the pull request, but since it has been brought to the list, I will do it here and now. This change has grown and grown, and become somewhat of a moving target. The original request was: output the user for the environment when switching I take some of the blame for this by not splitting the command up when I initially wrote it. 'switch' has an alias of 'env' and I always ended up using juju env to see what my current environment was, and juju switch to change it. This alone should have told me that I should have changed it, but I didn't. The core reason that the information is different at this stage is that we don't want to break any existing clients, but we do want to lay the foundations for changing the output on the next release. The idea that the output from the CLI may be being used and parsed by scripts. This was one of the key reasons to add the formatting options. My first implementation used a --env-info flag, but through review this was deemed to be not user friendly. I think the UX needs some discussion. Addressing the concerns, can we not: $ juju switch [env] $ juju info # display env info of env user just switched into OK, here is my proposal, which I hope addresses all the concerns and gives us a way forwards. This looks like a great direction, thanks. 1) juju switch with no args becomes deprecated (replaced by juju info) and will be removed one release following, continues to work as before 2) juju switch --list becomes deprecated (replaced by juju info) 3) juju switch new-env --format=[json,yaml] will output new information, but just environment name, old env name and username I don't see why the username creeps in here. As I understand it, switch is just about switching environments. If we keep it that way, I think it makes coherent sense as a command if we have these possible usages of it: juju switch environment-name switches to the environment with the given name. juju switch prints the name of the current environment. juju switch --list prints all possible environment names that can be switched to. Then the entire currency of the switch command is environment names. Then you don't have to use juju info to find out what things you can pass to juju switch, and there's very little overlap between switch ad info. In other words, I think the switch command we have currently is just about right. 4) juju env alias gets a deprecation warning (I'm sure we can work out when a command is called through the alias), and next version we switch the alias to be of 'info' not 'switch' +1 (except the last bit - I don't really think it's a particularly useful alias) 5) add a juju info command that outputs: * environment name * uuid - if we have it * api end points * CACert - if we have it +1 on all of these. FWIW, we *should* always have the UUID and CACert. * status - [running, stopped, and soon maybe suspended] I'm not sure about this. If this is supposed to be the current status of the environment, I'm -1 on it. I think this command should be about printing local info only - it can tell you what we know locally, but can work fast and independently of network or environment status. * username - supports json, yaml, and defaults to 'smart' +1 (but smart is such a rubbish name for a format :-)) - juju info becomes an environment command, so you can say juju info -e other-env - fields default to [environment-name, status, username] - all fields can be shown by using --all 6) juju info --list will output the list of environments in either yaml or json (or smart) Or perhaps just leave that to the
Re: $ juju switch --format
On Fri, Jun 6, 2014 at 9:49 AM, Nick Veitch nick.vei...@canonical.com wrote: sounds much better. Is there some way of throwing in whether HA is enabled in there too? I'm not sure that's very closely related to the purpose of the command. HA status is variable, and not a useful differentiator between environments; I think that every piece of information that doesn't function to identify a particular user/environment is suspect in this context. Cheers William -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: $ juju switch --format
As a user of juju swtich/juju env, I'd be sad to see it's very basic and straightforward operation go. For instance, I can run: $(juju env) at any time in a shell and know for certain what environment I'm targeting (and know immediately). It unwinds the mess that is env variable, default yaml env, switch env. That is useful like 'hostname' or 'whoami' are useful -- they may have limited functionality, but they do that job well. Just a thought. On Fri, Jun 6, 2014 at 3:34 AM, roger peppe rogpe...@gmail.com wrote: On 5 June 2014 23:16, Tim Penhey tim.pen...@canonical.com wrote: On 06/06/14 09:55, Jesse Meek wrote: I have a branch proposed that displays extra environment information when the --format flag is used with switch e.g: $ juju switch local --format yaml environ-name: local previous-environ-name: ec2 state-servers: - example.com - kremvax.ru username: joe There is some debate over this. Roger has summarised the key issues well in his review comment: I think this is a bit odd. In every other command AFAIK, choosing a format does not affect the actual information displayed, just the format that it's printed in. Why are we printing all this info with the switch command anyway? Personally I'd think that a new command was warranted here, perhaps juju current, or juju show or juju info. I was going to comment on the pull request, but since it has been brought to the list, I will do it here and now. This change has grown and grown, and become somewhat of a moving target. The original request was: output the user for the environment when switching I take some of the blame for this by not splitting the command up when I initially wrote it. 'switch' has an alias of 'env' and I always ended up using juju env to see what my current environment was, and juju switch to change it. This alone should have told me that I should have changed it, but I didn't. The core reason that the information is different at this stage is that we don't want to break any existing clients, but we do want to lay the foundations for changing the output on the next release. The idea that the output from the CLI may be being used and parsed by scripts. This was one of the key reasons to add the formatting options. My first implementation used a --env-info flag, but through review this was deemed to be not user friendly. I think the UX needs some discussion. Addressing the concerns, can we not: $ juju switch [env] $ juju info # display env info of env user just switched into OK, here is my proposal, which I hope addresses all the concerns and gives us a way forwards. This looks like a great direction, thanks. 1) juju switch with no args becomes deprecated (replaced by juju info) and will be removed one release following, continues to work as before 2) juju switch --list becomes deprecated (replaced by juju info) 3) juju switch new-env --format=[json,yaml] will output new information, but just environment name, old env name and username I don't see why the username creeps in here. As I understand it, switch is just about switching environments. If we keep it that way, I think it makes coherent sense as a command if we have these possible usages of it: juju switch environment-name switches to the environment with the given name. juju switch prints the name of the current environment. juju switch --list prints all possible environment names that can be switched to. Then the entire currency of the switch command is environment names. Then you don't have to use juju info to find out what things you can pass to juju switch, and there's very little overlap between switch ad info. In other words, I think the switch command we have currently is just about right. 4) juju env alias gets a deprecation warning (I'm sure we can work out when a command is called through the alias), and next version we switch the alias to be of 'info' not 'switch' +1 (except the last bit - I don't really think it's a particularly useful alias) 5) add a juju info command that outputs: * environment name * uuid - if we have it * api end points * CACert - if we have it +1 on all of these. FWIW, we *should* always have the UUID and CACert. * status - [running, stopped, and soon maybe suspended] I'm not sure about this. If this is supposed to be the current status of the environment, I'm -1 on it. I think this command should be about printing local info only - it can tell you what we know locally, but can work fast and independently of network or environment status. * username - supports json, yaml, and defaults to 'smart' +1 (but smart is such a rubbish name for a format :-)) - juju info becomes an environment command, so you can say juju info -e other-env - fields default to
Re: $ juju switch --format
Hi William, On Fri, Jun 06, 2014 at 07:40:47PM +0200, William Reade wrote: To restate your point, I think: you want to be able to keep seeing and reading simple names for the contexts you have available to work in. Yes. Agreed. Do the following use cases express your needs (even if you weren't hitherto aware that you were specifically manipulating environment *connections*)? Ah, ok, things are changing, got it. Making sure patterns like the following are still easily grok-able (even if it's a different command) is nice: juju destroy-environment $(juju env) Juju env used to print a lot of decoration around the environment name, IIRC it was like: $ juju env Current Environment: local (from JUJU_ENV) $ That was a lot to extract the name from. :) As a user, I want to be able to refer to particular environment connections by short simple names As a user, I want to be able to see what environment connections I have available As a user, I want to be able to see what environment connection is currently active I'd slightly modify to: As a user, I want to print without annotation the currently active environment connection If that even makes sense to do in the new world order. I'll leave that for you to judge. As a user, I want to be able to quickly activate a given environment connection As a user, I want to be able to see the details (env uuid, env name, state-servers, etc) of my environment connections Agreed with the rest. Thanks for writing those out. I see that there are changes coming, and I'm looking forward to what you have in store. Thanks to all for taking the time to consider the issues involved. Good to see you are taking seriously existing scripts, the burden of maintaining old ways of doing things going forward, progress, etc. -- David Britton david.brit...@canonical.com -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: $ juju switch --format
+1 On Thu, Jun 5, 2014 at 6:16 PM, Tim Penhey tim.pen...@canonical.com wrote: On 06/06/14 09:55, Jesse Meek wrote: I have a branch proposed that displays extra environment information when the --format flag is used with switch e.g: $ juju switch local --format yaml environ-name: local previous-environ-name: ec2 state-servers: - example.com - kremvax.ru username: joe There is some debate over this. Roger has summarised the key issues well in his review comment: I think this is a bit odd. In every other command AFAIK, choosing a format does not affect the actual information displayed, just the format that it's printed in. Why are we printing all this info with the switch command anyway? Personally I'd think that a new command was warranted here, perhaps juju current, or juju show or juju info. I was going to comment on the pull request, but since it has been brought to the list, I will do it here and now. This change has grown and grown, and become somewhat of a moving target. The original request was: output the user for the environment when switching I take some of the blame for this by not splitting the command up when I initially wrote it. 'switch' has an alias of 'env' and I always ended up using juju env to see what my current environment was, and juju switch to change it. This alone should have told me that I should have changed it, but I didn't. The core reason that the information is different at this stage is that we don't want to break any existing clients, but we do want to lay the foundations for changing the output on the next release. The idea that the output from the CLI may be being used and parsed by scripts. This was one of the key reasons to add the formatting options. My first implementation used a --env-info flag, but through review this was deemed to be not user friendly. I think the UX needs some discussion. Addressing the concerns, can we not: $ juju switch [env] $ juju info # display env info of env user just switched into OK, here is my proposal, which I hope addresses all the concerns and gives us a way forwards. 1) juju switch with no args becomes deprecated (replaced by juju info) and will be removed one release following, continues to work as before 2) juju switch --list becomes deprecated (replaced by juju info) 3) juju switch new-env --format=[json,yaml] will output new information, but just environment name, old env name and username 4) juju env alias gets a deprecation warning (I'm sure we can work out when a command is called through the alias), and next version we switch the alias to be of 'info' not 'switch' 5) add a juju info command that outputs: * environment name * uuid - if we have it * api end points * CACert - if we have it * status - [running, stopped, and soon maybe suspended] * username - supports json, yaml, and defaults to 'smart' - juju info becomes an environment command, so you can say juju info -e other-env - fields default to [environment-name, status, username] - all fields can be shown by using --all 6) juju info --list will output the list of environments in either yaml or json (or smart) In all honesty, I should have done this originally. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
