Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Thanks for reporting this. This is indeed a wrong in the way we currently call the lifecycle API from the command line interface.

So what's happening? The command line interface currently calls get_available_transitions and returns a list of all possible transitions of the state machine. However, all these transitions are actually the unique id's of each individual transition which describes the complete graph of the state machine. That's why you see transitions such as configure_error. This is for example the unique (internal) id of the transition from the transition state configurING to error_processing, which you are not able to trigger from the outside. It just happens to have configure, cleanup, activate and deactivate (as the internal ID and the transitions you can trigger) as they are uniquely defined for one action to take. In the case of shutdown, there are - as you've figured out - multiple occasions where you could call it. That's why you have unique IDs for shutdown from each of these states: unconfigured_shutdown, inactive_shutdown, active_shutdown.

This service is nice because it lets you introspect the complete state machine, but I agree it's in fact not the list of transitions you really want. What you want is to have a list of transitions you can currently trigger on a specific state. For this we need another service which returns that list.

I ticketed the issue here: