Do you mean on the hostinfo page?

I suppose we could invert the sense of the word. Perhaps:

1. change the heading to busy and show some representation of not(ready)
2. use some something other than the check/X. Maybe just yes/no?
3. pet some additional info on hover text for both heading and values
4. maybe also a docs page on interpeting this data that could be linked

Alternately, collapse the two columns into a single status.

1. green - "ready" - i.e. enabled and ready
2. red - "disabled"
3. yellow - "busy" - i.e. enabled and not ready

(plus still include helpful info in mouseover text and perhaps a docs link somewhere)

What about another state - "not ready and have not checked in for some interval (e.g. sleeptime * 2), so we can expect that builder is dead"?

1. red - "disabled"

I would vote for
- disabled as gray
- "have not checked in for some interval" as Error / Problematic / Offline and some info of no response time somewhere like mouseover text?

"not ready and have not checked in for some interval"

Ah, I was thinking similarly before. I left my initial notion out because the scheduler will automatically mark hosts not-ready after a timeout, but it would be good to distinguish the stale hosts from the merely busy.

The config for this is maybe a little tricky. We already have the ready_timeout setting on the hub, but the web can't see that, and each host has their sleeptime setting, but that is only known on the host. I guess as a first pass, we can duplicate the the ready_timeout setting in the webui. Alternately, we can add new data into the host table to let the scheduler mark this.

disabled as gray

ah good point. disabled is a normal situation and should not be alarming.

So I guess we're at

• green - "ready" - i.e. enabled and ready
• yellow - "busy" - i.e. enabled and checking in, but not ready
• red - "problem" (?) - enabled but not checking in
• gray - "disabled" - marked disabled (whether checking in or not)

Just a reminder that many people in the world have various red/green color blindness, so if you do use colors, you should also use a icon or other indicator too.

Just a reminder that many people in the world have various red/green color blindness

Ah, very good point.

Text colors will be set in css class of course, though we currently just have images in these columns. Internally, the images are selected via the imageTag function which works with the theme config.

I think we already have some sensible theme images and css classes to use here for most cases. E.g.

• "ready" -- use ready.png and class true (i.e. the green check we see all over)
• "busy" -- use building.png and class building (i.e. the same as for a running task)
• "problem" -- use failed.png and class false (i.e. the red bar we see now)
• "disabled" -- here we probably a new icon/class. Possibly, we could use deleted,expired, or canceled pngs, but none seem quite right to me. For class, we don't currently define a table cell class with grey text. We might just leave the class unset in this case, unless we want to define a new class (possibly impacting custom themes).

PR 4551

After looking at the current PR in the browser, a couple things jumped out at me:

1. the word "problem" is not very clear. Perhaps a more descriptive word like:
   • timeout (probably my fav)
   • offline
   • stale
   • overdue
   • unresponsive
   • delayed
2. Having just the icon is not as clear as I would like. Hover text is slow and requires user action. Perhaps text + icon for this?

What do folks think here?

OTOH, since handling the simulated state in PR #4551 is proving to be a little messy, perhaps this something like the alternate approach from my earlier comment. I.e.

1. Keep the separate columns (no simulated state)
2. Invert the sense of the other column in the UI -- "busy" == not(ready)
3. (but still accept ready as a url arg for backwards compat)
4. Avoid scary red bar logos in the "busy" column
5. Alert about timeouts in the last update column. E.g.
   • change the color of the timestamp text
   • include a warning logo for too-old timestamps
   • use the scary red bar logo for missing timestamps

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/4549

Please continue any further discussion there.