Skip to content

Notes from Second User test

The recording of this session is stored in my home directory on our shared drive (only accessible to ISC staff, sorry). Note that the application refresh was particularly slow during this session so a few observations may be due to that (perhaps the screen would have updated if he had waited longer.)

  • As with the first user, this user wanted to add new machines under settings, or under hosts. However, when subsequently looking for machines, was perfectly able to find them under the services menu. Perhaps add a link on the Stork settings page to the Machines page? #386 (closed)

  • Tracking from one screen to another is still confusing, even for a fairly experienced user. "I am not finding ID numbers useful." Initially thought the ID number was for the host, not the app.

  • The AppID is one key that is available on multiple screens. Consider permitting the user to alias that to a term that is more meaningful to the user. If we do that, please reflect the alias everywhere we currently have AppID.

  • The user tried to look at the scopes held by each member of the HA pair. This information doesn't seem to be available. He also seemed to think that HA was not configured correctly because the standby machine reported it was not serving any scopes. I think that is as designed, but perhaps we could use a tip under HA/ scopes to say that if the server is not presently active, no scopes will be shown. #387 (closed)

  • The user felt that a time-series graph of the # of addresses in each subnet is not useful. (Grafana) (no action)

  • Grafana, # of leases assigned was not clear enough to the user. Are these active leases? User thought the # of leases assigned was not very useful. (we decided to leave this for now and see if any other users find this confusing)

  • The user was not satisfied with the CPU load factor shown. Look at around minute 35 of the recording. The user disagrees with the definition of CPU load displayed. (@godfryd to view the tape to see if he can discover the issue. The display we are using is a standard OS function.)

  • This user thought that the DHCP administrator would not be responsible for upgrading the OS on the hosts and thought that a DHCP dashboard is not the right place to monitor OS versions. (no action - this will vary by the organization size and complexity.)

  • In the Kea detail app view, couldn't tell if the display was communicating which hooks are installed on disk or which hooks are actually loaded. Might be something to check in the documentation. (we decided to leave this for now and see if any other users find this confusing)

  • The user was easily able to turn off monitoring for a specific daemon. The user was not confused about the ability to separately turn off monitoring for the daemon vs the CA. (no action required)

  • When clicking on the More button on the dashboard under the subnets display, it should display just the DHCPv4 or DHCPv6 subnets (depending on which More button is clicked). #389 (closed)

  • When the user disabled monitoring on the agent-kea6 application, the subnets on that application did not disappear from the subnets list. The same occurred with turning off monitoring for a DHCPv4 daemon. Utilization numbers on the subnets on this application that was not supposed to be monitored kept updating in Stork. This seems like a bug. #390

  • The user suggested he would like to 'ignore' or stop monitoring a specific subnet. (I think that what he really wanted to do was to no longer see alerts on high utilization on that subnet.) (No action at this time.)

  • Some of the events are initiated by a User. Please provide a way to determine from the event which Stork user made the change (e.g. monitoring on/off, adding or removing a machine) #388 (closed)

  • The user was expecting when clicking on an event in the dashboard to drill down on the event, not to navigate to the app the event related to. (at the moment there IS no more detail, but if we add events with more detail, we will consider this) No action at this time.

  • The user is OK with not being able to see details on a machine that was removed, but the user wants to retain events associated with removed machine (what user removed the machine, when, etc). #357 (closed)

  • The user would like to see MORE on the events panel to see more event history. (#357 (closed))

  • The user had no difficulty finding and viewing the log tail. (no action)

  • On the Subnets list, the user thought it would be more helpful in the last column to show the hostname, instead of the IP address. [Not everyone will have defined hostnames and screen real estate is an issue. We discussed adding a hostname field, and having it hidden by default, with a configuration option to display it.] #391

  • The user observed that it would be helpful to have names for the subnets in some situations. If the subnets have names (perhaps use the comment field?) in the Kea configuration, it would be good to have an option here to display that comment/name rather than address/mask.

  • When we have alerting, the user will require per-subnet alerting rules.

  • On the drill down for the machine, it would be helpful to display the IP address.

  • On the summary list of machines, it the AppID@Address field is not really helpful The user would prefer to see the hostname, or at least, for whatever they DO see, they would like to see it reflected in the drill down they see when they click on the AppID@ link.

  • On the drill down for an individual machine, the admin can rename the machine 'address.' This is reflected as 'Location' on the summary Machines panel. We should use the same term in both places.

  • On the drill down for an individual machine, the admin can rename the machine 'address.' If what we are doing is permitting the admin to add an alias, we should be clearer about that (that this is a 'tag' or alias, not a new or different ip address necessarily). We also need to provide info about what sort of name is permitted (the user tried to add a name with spaces and that didn't work).

  • On the drill down for an individual machine, the admin can rename the machine 'address', including the port. If the user changes both and there is a failure, there is no feedback about which change caused the failure. Perhaps these should be separate change dialogs, or we should not permit changing the port number, if this is intended to be an alias,

  • In this instance, we changed the machine address to one that did not work, and the user did not notice/realize that the machine was no longer being monitored. Perhaps we should grey out the display of the cached information on a machine we can no longer reach so it is more obvious that this is old information. There is a message at the bottom of the machine detail panel saying that the machine was unreachable, but the user did not notice this.

  • This user would like to be able to provide an alias for the APPID - some name that is more meaningful to the administrator

  • The user commented that he liked the (?) info boxes.

  • The user was surprised that the Grafana menu item under services went to an external application. This should probably open in a new window, rather than taking the user out of Stork.

  • User wondered - "why are the DHCP services not under the DHCP menu? It is obviously DHCP...."

  • The user kept looking for machine information under Hosts. Consider renaming that 'Reservations' to avoid confusion with host machines.

  • This user felt that the list of pools per subnet could be in a subnet drill down, rather than on the summary list of subnets. The user would also like to see a name for the subnet, if the subnet has a name in the Kea configuration (not sure if this is even supported)

  • On the subnets list summary page, the far right column, the user requested that this be two links one to the machine and one to the app (clicking on either goes to the app).

Edited by Vicky Risk