Supervisor actions

[jlashner]

Provides various updates to the HWP Supervisor required for site use.

Description

This PR adds some changes that are necessary for the Supervisor to be run through sorunlib and the scheduler. Mainly, we needed a better way to track if a user-commanded operation has finished, and to determine if it was successful.

Currently, the supervisor is done by a fairly simple state machine, where agent tasks would put the machine in a particular state, and states could put the machine into a new state depending on the update function.

This PR modifies this a bit, by grouping states together into "Actions", based around user requests. Now, when a user runs an operation like pid_to_freq, instead of just setting the PidToFreq state, this will request a new Action that begins in the PidToFreq state. This action can be monitored until it enters a "completed" state (i.e. Done, Error, or Abort) at which point the action will no longer be modified. Actions provide a bit more extra book-keeping, including a unique id, the current state, the state-history of the action, and whether the action is completed and successful.

Tasks now will create an action, and monitor it until the action is completed, at which point the task will finish.

An action can be aborted by running the abort_action task, which will put the current action into the "Abort" state at the next opportunity, and will put the state machine into an idle state.

Note: This requires changes from the hwp-emulation branch, so I set that as the base. I can change that after hwp-emulator is merged in.

Motivation and Context

Necessary behavior changes in order to add to next-line

How Has This Been Tested?

Certain operations such as pid_to_freq, and pmx_off have been tested with the HWP emulator. We hope to be able to be able to test more on a real platform.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[BrianJKoopman]

Now that the tests in #606 are working can you rebase this?

[BrianJKoopman]

This is look good. My comments/questions are mostly:

• Documentation change requests/comments
• Asking for clarification on how abort works
• Checking in on task success verification and wondering what happens when Supervisor agent tasks fail

[jlashner]

Hi Brian, updated docs and tried to address all of your comments, so if you could re-review that would be great.

In the RST I added a couple of paragraphs that try to explain what a Control Action is within the agent. They are pretty much one-to-one with OCS operations, so its almost interchangeable, but not exactly the same thing.

[BrianJKoopman]

(Sorry, botched the review -- GitHub's comment response options make that easy to do, more comments.)

Thanks for the docs updates, the new section on Actions cleared things up for me. I do think we need to return action.success, instead of just True all the time. Other than that, looks good!

[jlashner]

Hey brian, just submitted a commit that addresses your last piece of feedback

[BrianJKoopman]

Looks good, thanks for the updates!