Open Stack

> As I said elsewhere in this thread, if you're proposing to add a new
> policy rule to change the 'status' field based on host_status, why not
> just tell people to open up the policy rule we already have for the
> host_status field so non-admins can see it in their server details?
> This sounds like an education problem more than a technical problem to
> me.

Yeah, I'm much more in favor of this, unsurprisingly.

It also avoids the case where a script is polling for an instance's
state, and if it becomes anything other than ACTIVE, it takes action or
wakes someone up. If you've just taken the compute service down for an
upgrade (or rabbit took a dump) you don't end up freaking out because
"the instance has changed state" which is what that looks like from the
outside. If you _want_ to take action based on the host's state, then
you look at that attribute (if allowed) and make decisions thusly.

> Also, --fields is one thing on one interface to the API. Microversions
> are opt-in on purpose to avoid backward incompatible and behavior
> changes to the client, so if the client has a need to know this
> information, they can opt into getting it via the host_status field by
> using the 2.16 microversion or higher. That's the case for any
> microversion that adds new fields like the embedded instance.flavor
> details in 2.47 - we didn't just say "let's add a new policy rule to
> expose those details".

Clearly we couldn't return the UNKNOWN state if the request was from
before whatever microversion we enable this in.

> The down-cell UNKNOWN stuff is also opt-in behavior using the 2.69
> microversion. I would likely only get behind changing the behavior of
> the 'status' field based on the compute service status in a new
> microversion, and then we have to talk about whether or not the
> response should mirror the down-cell case where we return partial
> results. That all sounds like a lot more work than just educating
> people about the host_status field and the existing policy rule to
> expose it.

I actually think if we're going to do this, we *should* make
compute-down mirror cell-down in terms of what we return. I think that's
unfortunate, mind you, but otherwise we'd be effectively re-writing what
we said in the down-cell microversion, going from "If it's UNKNOWN,
expect the instance to look like the minimal version" to "Well, that
depends...". It would mean that something using the later microversion
would no longer be able to check for UNKNOWN to determine if there's a
full instance to look at, and instead would have to poke for keys.

--Dan