I wanted to propose some suggestions here. I think right now the idea is that this command is really fast using cached information and we should be aware that adding live data means we'll need to sync this up. This has to happen anyway, but it means there is a chance for it to be a bit out of date.
That said, I like the idea of some important top level information. I tried to setup a sample use case and put together some examples of what output would/could look like here.
Taking each in line. The ADDRESS is interesting, but I'm curious when/how you use that address info in regular Juju use. I'm also concerned that in my lxd controller my first address is actually IPV6 and it eats up a lot of space and I'm not sure that the value of having it here brings. What use case is this address drives the desire to see it here on the high level command used frequently?
The UNITS I like a lot, but I'd like to propose offering it as a way to gain visibility into HA status. We don't currently have that, and if it's degraded, or not HA, then I think it deserves high level attention. I've proposed in #2/#3 to expose that more as a true, false, degraded value set vs a number of units. Especially because units here feels a bit overloaded and I'd prefer to help the user translate the number into meaning (e.g. 2 means degraded vs just showing a 2).
The instance id is interesting as well in the single case. I could see wanting to be able to map the instance id to your controller endpoints in the cloud control panel and making sure you don't touch them. However, if that's the use case then I feel we'd want to display each id when the controller is in HA mode. Again, the size requirements and mental overhead of those strings I'm not sure are worth the space in day to day use. I DO think that we should add those to the show-controller output though. Currently you have to do:
juju switch azure-test:controller
juju status
to get the list of those ids from the machine section of status.
I'd like to propose that we approach this with adding HA details, adding instance ids to the show-controller output, and the addresses are already in the show-controller output. This plus fixing the visibility issues with HA as a whole (lp:1602749) will be a nice improvement in usability imo.
I wanted to propose some suggestions here. I think right now the idea is that this command is really fast using cached information and we should be aware that adding live data means we'll need to sync this up. This has to happen anyway, but it means there is a chance for it to be a bit out of date.
That said, I like the idea of some important top level information. I tried to setup a sample use case and put together some examples of what output would/could look like here.
Examples/proposals are located at http:// paste.ubuntu. com/19282424/ to help with formatting visibility.
Taking each in line. The ADDRESS is interesting, but I'm curious when/how you use that address info in regular Juju use. I'm also concerned that in my lxd controller my first address is actually IPV6 and it eats up a lot of space and I'm not sure that the value of having it here brings. What use case is this address drives the desire to see it here on the high level command used frequently?
The UNITS I like a lot, but I'd like to propose offering it as a way to gain visibility into HA status. We don't currently have that, and if it's degraded, or not HA, then I think it deserves high level attention. I've proposed in #2/#3 to expose that more as a true, false, degraded value set vs a number of units. Especially because units here feels a bit overloaded and I'd prefer to help the user translate the number into meaning (e.g. 2 means degraded vs just showing a 2).
The instance id is interesting as well in the single case. I could see wanting to be able to map the instance id to your controller endpoints in the cloud control panel and making sure you don't touch them. However, if that's the use case then I feel we'd want to display each id when the controller is in HA mode. Again, the size requirements and mental overhead of those strings I'm not sure are worth the space in day to day use. I DO think that we should add those to the show-controller output though. Currently you have to do:
juju switch azure-test: controller
juju status
to get the list of those ids from the machine section of status.
I'd like to propose that we approach this with adding HA details, adding instance ids to the show-controller output, and the addresses are already in the show-controller output. This plus fixing the visibility issues with HA as a whole (lp:1602749) will be a nice improvement in usability imo.
Thoughts?