Show controller instances in 'juju controllers'
Bug #1600453 reported by
Mark Shuttleworth
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
Medium
|
Ian Booth |
Bug Description
Currently we show the following output from 'juju controllers':
CONTROLLER MODEL USER CLOUD/REGION
ms-goog-eu* k8s admin@local google/europe-west1
I'd like to add more information to give some sense of:
* the number of machines providing the controller (1, 3 etc)
* the contact URL / address (just one of them?)
Possibly also:
* the machine instance type?
For example:
CONTROLLER MODEL USER CLOUD/REGION ADDRESS UNITS INSTANCE
ms-goog-eu* k8s admin@local google/europe-west1 103.22.35.211 1 juju-324d5a-0
Changed in juju-core: | |
status: | New → Triaged |
importance: | Undecided → Medium |
tags: | added: 2.0 usability |
Changed in juju-core: | |
milestone: | none → 2.0.0 |
affects: | juju-core → juju |
Changed in juju: | |
milestone: | 2.0.0 → none |
milestone: | none → 2.0.0 |
Changed in juju: | |
milestone: | 2.0.0 → 2.0-beta18 |
assignee: | nobody → Ian Booth (wallyworld) |
status: | Triaged → In Progress |
Changed in juju: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
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?