The basic theme here is to organize the main.yml of the role into smaller sub-sets consisting of install.yml and enable,yml and the logic to tell if the role is requested to install by having '_install: True' in a "vars file". Once this install action of the role is completed the last thing done is the '_installed: True' "note the 'ed' at the end" flag is written to config_vars2.yml and proceeds to the enable.yml that contains the logic to enable|disable the role's service based on the '*_enable: True' then updating iiab.ini with the currently requested state.

Once the role is installed any second running of the role enable.yml will always run due to the '_installed: True' entry in config_vars2 while install.yml will not thus speeding up execution time while guarding against a user who mistakenly toggles '_install: False' after a pass with the value set to True, giving the code a path to disable the service via '*_installed: True'

Roles that have a database backend that need to have the database running to configure are split out to a sub file I called prov-db.yml, those can't be run under chroot in pi-gen, thus having the 'not installing' exception. Now this would generally be after install.yml, as it is a soft config that just needs the credentials to create/configure the database backend for the role.

The introduction of iiab-configure is to allow the re-running of stages 4-9 post-install to pickup changes to local_vars.yml "just like ICO" including installing new roles not previously installed if requested while avoiding any costly actions for roles already installed|functioning, ensuring all the '*_enabled' options of the end users' current edits of local_vars are respected.

Thanks @jvonau for the many good ideas that I hope @georgejhunt & @tim-moody can comment on in coming days.

(A model/minimal/stub/mockup playbook could also be very useful here — to make clear what we're shooting for — and most importantly helping outside developers efficiently go from "zero to hero" as @m-anish mentions in his early 2019 IIAB video.)

Refs:
#1937 "pi-gen"
#2009 "Nginx shim for local_vars_big"

(A model/minimal/stub/mockup playbook could also be very useful here — to make clear what we're shooting for — and most importantly helping outside developers efficiently go from "zero to hero" as @m-anish mentions in his early 2019 IIAB video.)

A good place to post this model/minimal/mockup proposed playbook would be somewhere in https://github.com/iiab/iiab/wiki/IIAB-Contributors-Guide#ansible !?

superceded by #2031