s/Tiis/This, and specifcally I'm referring to http://beaker-project.org/dev/guide/code-guidelines.html#api-stability

Bug 1037592 makes this more significant, since it will make a clear distinction between the system status (overall dynamic state) and the condition (the automated/manual/broken/removed setting).

I'm not sure we need to worry about deprecating --status, but adding --condition and hiding --status from the help output would certainly be a good thing to do.

Hmm, I just noticed we also call it "Status" in the web UI search options as well. The only place where we currently use "condition" is the system details page.

I prefer the more specific "Condition" name, though, since "status" is a bit too broad (reserved or not, loaned or not also factor in to the overall status)

This comes back to the underlying issue with this field that we have discussed before. In spite of its varying labels, it is neither a "status" nor a "condition" but an answer to three orthogonal questions:

1. Is this system still in Beaker's inventory, or has it been removed?
2. Is this system available to the scheduler, or can people take it manually?
3. Is this system temporarily out of service due to some of kind of fault?

I think whatever changes we make to naming should work towards clarifying these three independent meanings. For example in my system page mockups I had used the wording "Operational" and "Out of service".

Right, it's really:

Presence: Removed vs Installed
Condition (installed systems only): Out of Service vs Operational
Usage mode (operational systems only): Automated vs Manual

It's just encoded as a single status field:

Removed
Broken (Installed, Out of Service)
Manual (Installed, Operational)
Automated (Installed, Operational)

So perhaps we should report it that way here?

Installed: true/false
Operational: true/false
Automated: true/false

Currently, the only combinations we would report are:

Removed (all false)
Broken (installed true, others both false)
Manual (installed and operational true, automated false)
Automated (all true)

Whilst I mostly agree with Dan's comment, I don't think the answers that condition provide are completely orthogonal to each other. After all, they all tell us what kind of behaviour we can expect from the systems at a base level (before permissions etc come into play), and are a handy reference point for (experienced) users. The nice thing about it is that I can look at a single label and understand the situation, rather than having to look at three times as many labels to gleam the same information.

Having said that though, I think that splitting it up probably will be better in the long run and will make things more clearer (both in the code and for the user), at the expense of succinctness. 

Also, I would be hesitant about using 'Installed' as the opposite of 'Removed' as it could easily be confused with the notion there is a distro currently installed on the system. Really the opposite would be 'Added', but that may sound weird to some ears as well.

Anyway, I don't think we would want to make a change like this (in the backend or frontend) in a maintenance release.

(In reply to Raymond Mancy from comment #7)
> Whilst I mostly agree with Dan's comment, I don't think the answers that
> condition provide are completely orthogonal to each other. After all, they
> all tell us what kind of behaviour we can expect from the systems at a base
> level (before permissions etc come into play), and are a handy reference
> point for (experienced) users. The nice thing about it is that I can look at
> a single label and understand the situation, rather than having to look at
> three times as many labels to gleam the same information.

I disagree. Encoding all three things in one value actually gives you less information.

Firstly, Removed systems should never be shown in any search results or listings at all, unless the user explicitly opts in to seeing them. We expect "Removed" to be a permanent thing -- the system is never coming back, it is only useful as a historical reference. (Of course the system could come back, but that is not the intended meaning of Removed.) So it does not make sense to treat Removed systems in the same way as everything else.

Next, the big problem with the Broken status is that it does not indicate what the status normally would be if it weren't broken. So yes, if I see a system is Broken I know that the scheduler won't pick it for me right now. But when it gets fixed tomorrow, will the scheduler pick it, or will it be set back to Manual? Similarly, the owner/admin who takes it out of service has to actually think (either remember, or look in the activity) to figure out what status to pick when the system is no longer broken.

And the Manual vs. Automated distinction is an indication of "will the scheduler pick this system for me" but as we know it is far from the only factor which affects that. And an Automated system can still be taken manually (but only under certain circumstances!) So this is more just an indication of how the owner intended the system to be used, especially since if you have suitable access you can easily change the system from Manual to Automated. Moreover I think we should be working to eliminate Manual by allowing things like recipes which skip provisioning and unlimited reservations when allowed by the owner.

So my point is just that encoding this state in a single field, and displaying it as such to users, means that we are probably not giving them the information they need in an efficient way.

Sounds like a suitable topic for a design proposal to me - "Clarifying reporting of system status" or something like that.

We won't be able to explain it clearly to users until we're completely clear on the problems with the status quo ourselves.

The event driven scheduler proposal is also related (since that adds the idle/scheduled/waiting/installing/running/pending dynamic state machine for systems) and bug 1037592 should use terminology consistent with any such proposal.