Policy rule for host status is UNKNOWN
Today, the status of a server is shown as ACTIVE when nova believes it should
be running. However, when there is an interruption in communication between
nova-api and nova-compute greater than the configured ``service_
the server status still shows as ACTIVE, even though nova knows it is actually
unknown. The server might be running or shutoff; it is unknown.
The ``host_status`` field will show the status of the underlying compute host
with a policy ``os_compute_
admin-only. This is an all or nothing set of host statuses including: ``UP``,
``DOWN``, ``MAINTENANCE``, and ``UNKNOWN``. Some operators may not wish to
expose details such as compute host status: ``UP``, ``DOWN``, or
``MAINTENANCE`` to end users a public cloud, for example.
We propose that we add a new API policy rule
``os_compute_
``admin_api`` which will show a ``host_status`` of ``UNKNOWN`` if the
``get_instance_
``host_status`` field will not be returned. Today, the ``host_status`` field
is not included in the server response for non-admin users by default.
This is proposed as a user experience improvement for non-admin end users to
receive more transparent information about what to expect about their server
status than they have today.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Low
- Drafter:
- melanie witt
- Direction:
- Approved
- Assignee:
- melanie witt
- Definition:
- Approved
- Series goal:
- Accepted for ussuri
- Implementation:
-
Implemented
- Milestone target:
-
ussuri-2
- Started by
- Matt Riedemann
- Completed by
- Eric Fried
Related branches
Related bugs
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
Propose showing server status UNKNOWN when host status UNKNOWN
Gerrit topic: https:/
mriedem 20190801: I'm definitely more on board with the idea proposed in the blueprint description than the earlier revisions of the spec that changed the server status based on the host_status. A few thoughts/concerns:
- The proposed policy rule should conform to the new rules, e.g. "compute" prefix and such: https:/
- The host_status field is only returned for microversion >= 2.16 today - that should stay the same here regardless of policy.
- Since host_status in the response is conditional on passing a policy check today (admin or not) I think that should remain if the non-admin passes the policy check but the host_status is not UNKNOWN, e.g. if the non-admin with microversion 2.16 has host_status=DOWN then we'd NOT return the host_status field in the response.
- Keep an eye on performance impacts when listing servers with details since we don't want to have to make the same policy check per server while listing servers, so can we cache that or re-use a variable or something. This is an implementation detail but I'm reminded of https:/
- Following on the last point, I think the rule should, at least initially, default to admin-only to match the existing rule for backward compatibility and then deployers can opt into exposing this to their users. One could probably make an argument either way about what the default should be though, but I tend to opt for backward compatibility especially when there is no microversion gating this.
gibi: 20190805: I'm agree with mriedem's proposal above.
Gerrit topic: https:/
Addressed by: https:/
Add new policy rule for viewing host status UNKNOWN
[efried 20190829] Discussed in nova meeting, agreed that barring some solid justification for this to preempt other work already bp/spec-approved and code-ready, it doesn't make sense to add it to our already-full plate.
melwitt 20190829: So you’re gonna not approve this to prevent people from reviewing my 117 line patch if they feel like it? OK. ¯\_(ツ)_/¯
Putting this back that got removed during a mid-air collision:
Deferred to Ussuri, let's re-propose/discuss when that opens up. --
- mriedem 20100829
[mriedem 20191017] Per the nova meeting today:
http://
We agreed to approve this for Ussuri given melwitt said the patch accounts for the conditions above.
Gerrit topic: https:/
Gerrit topic: https:/
Addressed by: https:/
Follow-ups for host_status:
