Description of problem: It will be useful for plugins to be able to add sub-stages and declare that an event should run at some specific sub-stage. Sub-stages should then run without overlaps. Examples: 1. In engine-setup, during customization stage, we have "Product options", then "Packages", "Network configuration" etc. Currently these are hard-coded as events in several titles.py files. If two optional plugin packages want to add their own, they can't make sure their events will not be mixed. Also a solution to current bug might make it possible to not show the titles themselves during run if there are no questions to ask (or other output). 2. Each of engine and dwh have (among others) these two events: Provisioning (asking "Where is the XXX database located" and if 'local', asking "Would you like Setup to automatically configure postgresql"), then manual/remote Credentiuals ("database secured connection", "database name" etc). Currently they are mixed: First we prompt "Provisioning" for both, then "Credentials" for both. It's not easy to make them not mixed. It should be possible for engine plugin to define a sub-stage "Engine Database Customization" with both events in it, for DWH to define similar, and have them run one after the other. It's probably useful also to be able to define order for these sub-stages (e.g. for dwh to define it should run after engine). I didn't check deeply the exact current behavior, opening this bug based on reports. A workaround might be to rename the events, as by default otopi sorts events by name, after fulfilling before/after/priority requirements.
I started working on this some time ago [1] and it turned out to be more complex than expected, if I want to solve the most general case. Perhaps we should define a more strict subset that is still useful, if at all. We should also consider bug 1367457 and especially alt1 there. [1] https://gerrit.ovirt.org/#/q/project:otopi+status:open+message:substages
Closing for now. Might reopen in the future with more concrete needs and probably less general implementation. Above patches were abandoned, remove "status:open" if you want to look at them.