This is a basic, high-level summary of the flow of a BOS session. This assumes no multi-tenancy and no staged sessions. All communications between services are using their APIs, unless otherwise specified.
The administrator calls BOS to create a session template.
API server does some basic validation of the session template, then creates it in the BOS database.
The administrator calls BOS to create a
session to reboot a single xname (xname1).
The BOS API server does some basic validation of the session, then creates the pending session in the BOS database.
The session-setup operator (the next time it runs) notices the pending
session and processes it.
The operator performs further validation and determines that this session is targeting xname1.
The operator calls the BOS API to update the xname1 component as follows:
enabled field to true.session field to the name of the session.desired_state field to reflect the desired end state for the node.
This includes boot artifacts, power state, and CFS configuration.error field.last_action field to session_setup.actual_state field
(this forces BOS to reboot the node even if the target state happens to match the current state).Calls the BOS API to update the session as follows:
status field to running.components field to xname1.The status operator (the next time it runs) notices that the xname component is enabled and processes it.
The operator queries HSM, CFS, and
PCS in order to get state information about xname1.
For this example, assume that xname1 is currently booted.
The operator will discover this when it queries PCS for the power state of the node.
The status operator will call the BOS API to update the xname1 component to have
phase power-off-pending
The power-off-graceful operator (the next time it runs) notices the enabled component
in the power-off-pending phase.
It issues a power off command to PCS for the node, and then calls the BOS API to update the last_action field for the component
to power_off_gracefully_called.
The status operator will see that this has happened., and will check PCS to see if the node is powered off.
For this example, assume that PCS reports that the node is not powered off.
The status operator will update the component in BOS to have phase powering_off.
After max_power_off_wait_time has elapsed,
the next time the power-off-forceful operator
runs, it will notice that this time period has elapsed since the node had its power off request issued.
The operator will call PCS to do a forceful power off on the node, and then it will call the BOS API to update the
component to have last_action power_off_forcefully_called.
The status operator will see that this has happened, and will check PCS to see if the node is powered off.
For this example, assume that PCS still reports that the node is not powered off.
After max_power_off_wait_time has elapsed again, the next time the power-off-forceful operator runs,
it will notice that this time period has elapsed since this node had its power off request issued.
The operator will call PCS to do a forceful power off on the node, and it will update the BOS component
to have last_action power_off_forcefully_called.
Assume that the node finally powers off.
The next time the status operator runs, it will notice that xname1 has phase power_off_pending,
and that PCS reports its power state as off.
The operator will call the BOS API to update the component phase to be power_on_pending.
The next time the power-on operator runs, it will see xname1 is enabled
and has this phase. It does several things:
initrd; it records the token sent back by BSS.power_on_called.status operator will see this and update the component phase to powering_on.
When the BOS reporter runs on the node, it will contact BOS to update the actual state for xname1 with the BSS token for the node.
The API server will use that BSS token to look up the associate boot artifacts in the database, and update the component actual state with those as well.
The next time the status operator runs, it will see that xname1 is on and that its actual boot artifacts
match its desired boot artifacts.
It will check CFS to see if the desired configuration is set for the node. In this case, it is, because it was
set by the power-on operator.
So the status operator will check CFS to find the status of the node. It sees that it is in pending state.
The operator calls the BOS API to update the component phase to be configuring.
The configuration operator (the next time it runs) will notice this enabled
node in the configuring phase. It will check CFS to see if it has its desired configuration set. Since it
does, the operator does nothing.
Eventually the status operator runs and sees that xname1 has configured state in CFS.
This means the node has completely reached its desired state.
The operator calls the BOS API to update the component – it disabled it and clears its phase.
The next time the session-completion operator runs, it will look at the
session, since it is in the running state.
It will see that only BOS component which references this session is xname1, but that this component is disabled.
The operator will call the BOS API to update the session, updating the state to complete
and setting the end_time field.
The operator will call the BOS API to save the session status to the database.
Every time the session-cleanup operator runs, it issues a delete command to BOS.
This command is to delete all sessions which are complete and that completed longer ago than
cleanup_completed_session_ttl.
If the session was not manually deleted before this, it will be deleted at this time.