You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In an effort to make the logic clearer, we restructure the part(s) of
Xapi_pool_helpers responsible for determining which operations are
"valid" (i.e. become members of allowed_operations).
The previous code is somewhat tedious to understand because it is
unconditionally ineffective - the logical delineation of parts of the
code is implicit, as the code computes the valid operation table in
order, but many of the operations will have no effect (as later code to
populate an operation's entry in the validity table do nothing).
To try and simplify matters, we add some level of static partitioning of
"blocking" and "waiting" operations (using separate polymorphic variants
and coercions to widen into a type comprising all operations). Then, we
replace loops with "find first" computations.
The current logic should be clearer. It is roughly as follows:
To compute the "valid" operations:
- Start by assuming all operations are valid. We explicitly map each
operation to an "Allowed" constructor to signify this. Though,
technically, full coverage of the cases would guarantee that absence
from this table implies the associated operation is valid - however,
we maintain the old concern and maintain validity entries as a
tri-state value (Unknown, Allowed, and Disallowed).
- Determine the current operations reported by the pool object. At
present, every operation is statically partitioned into "blocking" or
"waiting" operations - which are both handled differently, with a
"blocking" operation taking highest precedence
- If there's an operation in current operations that is a blocking
operation, this takes precedence. We cover all operation cases as
follows: (1) blocking operations get marked as being invalid and cite
the reason associated with the blocking operation discovered in the
current operations set (which is an operation-specific "in progress"
error). Then, all waiting operations get marked as invalid, citing a
generic "in progress" error (unrelated to any specific operation).
- If there's no blocking operation in current operations, but there is a
waiting operation, we map all operations to a generic "in progress"
error.
- If there is no blocking or waiting operation in current operations
(which, at present, is to say that current operations is empty), then
we invalidate entries based on specific, hardcoded, invariants. For
example, if HA is enabled on the pool, we invalidate the `ha_enable`
operation on the pool object (with the reason explicitly explaining
that you HA is already enabled).
In future, we could consider encoding the relations between operations
(and related object state) declaratively, such that we can either
automatically generate such code (and test it alongside invariants,
encoded as Prolog-esque rules) or use an incremental computation
framework to automatically recompute the allowed operations based on
changes in ambient pool state.
Signed-off-by: Colin James <[email protected]>
0 commit comments