Try 'skip_role_on_error: True' in default_vars.yml for more uninterrupted installs of IIAB Apps ['./iiab-install --risky' if you want to live on the wild side, forcing it too to use 'skip_role_on_error: True']

[holta]

This PR sets skip_role_on_error: True in /opt/iiab/iiab/vars/default_vars.yml, causing ./runroles and Admin Console (e.g. preset learning bouquets, etc) to install IIAB Apps in a more uninterrupted way.

For now this will not affect ./iiab-install and ./runrole, as they are manually overriding this to skip_role_on_error: False for the moment.

Related:

• This protects the user when first installing, but does not protect later changes done by admin-console #3242
• I'm just pointing out that adm-console does not use these 2 files that are modified with this PR making things extremely fragile within the console until these workarounds goes away. #3244
• PR Prototype 'skip_role_on_error: True' in 4 roles {lokole, moodle, mongodb, sugarizer} #3255
• PR Support skip_role_on_error in 23+3 more roles (Stages 6-9) [and FreePBX module 'sipsettings' won't install?] #3256
• PR /usr/bin/iiab-apps-to-be-installed: Quick scan to see what's asked for but not yet installed #3257

[tim-moody]

If you don't want this for iiab-install I would put it in the playbook, not as a command line argument. Either way overriding default vars is a significant departure.

[holta]

./iiab-install and ./runrole have been calling Ansible with --extra-vars (for certain very-high-level vars) for many years now.

I believe that's generally a good thing for these very-high-level directives as it brings added transparency, showing these couple vars (and their values) quite prominently to the operator, seconds after they run the command.

[tim-moody]

reinstall is all I see. I don't see command line overriding default vars.

[jvonau]

Makes no sense that runrole with the idea to run a single role to debug the individual role, would skip to the end of the single role being run upon failure, now you have to scroll back or dig trough the logs to view an error. Just let the variable be user defined in local_vars,yml to suit the user's use case and the default should not change the current workflows. I can see where a user may want iiab-install to skip the role on failure, thought that would of been be the primary use for this new functionality, rush though and check later what failed. One can't do that with what you propose.

[tim-moody]

Makes no sense that runrole with the idea to run a single role to debug the individual role, would skip to the end of the single role being run upon failure, now you have to scroll back or dig trough the logs to view an error

I think @holta agrees with this and only wants to apply skip_role_on_error: True to Adm Cons runs and ./runroles

Just let the variable be user defined in local_vars,yml to suit the user's use case

But then I would have to change local vars every time I switch from a single role to multirole tests.

My only quibble is I would prefer the setting in the playbook, not the script.

BTW, iiab-network will currently pick up the value from default vars.

[jvonau]

Makes no sense that runrole with the idea to run a single role to debug the individual role, would skip to the end of the single role being run upon failure, now you have to scroll back or dig trough the logs to view an error

I think @holta agrees with this and only wants to apply skip_role_on_error: True to Adm Cons runs and ./runroles

What if the end-user doesn't want to troll through the logs to find the error and would prefer the run to stop at the error?

Just let the variable be user defined in local_vars,yml to suit the user's use case

But then I would have to change local vars every time I switch from a single role to multirole tests.

The admin-console already can alter local_vars, being a boolean could be another tick box somewhere and write the value wanted by the end user, or just write what mode admin-console wants to be use.

My only quibble is I would prefer the setting in the playbook, not the script.

That would defeat the purpose of making the variable defined in local_vars.yml

BTW, iiab-network will currently pick up the value from default vars.

The main network role seems to be exempt from this massive change. As this PR sits now there would be no way for iiab-install to use the value from local_vars when cmdline arguments trump all other vars used, rendering the setting of the value to True to be useless which was the way the process was debugged, showing the skipped roles during installation.

[holta]

FYI setting individual variables (like skip_role_on_error) in playbooks like iiab-stage.yml using lines below vars: is in fact a "noop" (i.e. it doesn't do anything at all) the reason being that vars_files: supersedes vars:

Of course one could create yet another vars file invoked by vars_files: (containing nothing but skip_role_on_error: True or skip_role_on_error: False) or create a multiplicity of additional local_vars_*.yml files, but I'm personally not in favor!

Here's an example (below) illustrating precedence — all vars set in the vars: sections are ignored (effectively) when any such var is also set within any of the vars_files:

---
- hosts: all
  become: yes

  vars:
    - skip_role_on_error: VALUE-THAT-IS-IGNORED

  vars_files:
    - roles/0-init/defaults/main.yml
    - vars/default_vars.yml
    - vars/{{ ansible_local.local_facts.os_ver }}.yml
    - /etc/iiab/local_vars.yml
    - /etc/iiab/iiab_state.yml

  vars:
    - skip_role_on_error: ANOTHER-VALUE-THAT-IS-IGNORED

  tasks:

  - debug:
      var: skip_role_on_error

[holta]

Addendum:

One could of course strip out the var skip_role_on_error from all vars files, to force playbooks (like iiab-stages.yml) to act on brand new spontaneous vars: declarations of individual variables like skip_role_on_error: True or skip_role_on_error: False.

(But such things feel very much like solutions-in-search-of-a-problem 😨)

[tim-moody]

One could of course strip out the var skip_role_on_error from all vars files

all one of them?

that's what I would have done.

https://github.com/iiab/iiab-admin-console/blob/master/iiab-admin.yml works this way.

[holta]

The entire UX / mental framework / workflow (of things like ./iiab-install and sudo iiab) is built around the notion that "INTERNET-IN-A-BOX (IIAB) SOFTWARE INSTALL IS COMPLETE" is prominently displayed, to confirm to implementer folk that they're over the hump (as Mitra Ardron strongly advocated for — and has helped many people since!)

Allowing everyone to set skip_role_on_error: True in /etc/iiab/local_vars.yml and thereby falsely declare victory as soon as they see "INTERNET-IN-A-BOX (IIAB) SOFTWARE INSTALL IS COMPLETE" would create havoc 😩

Quite separately we can create another ./iiab-install-piecewise or ./iiab-install-best-effort (or whatever) as we choose. But this will be a quite different way to skin the cat, evolving forward with a quite different UX — i.e. setting very different expectations with different documentation/videos/affordances/etc (it can take much-more-than-a-year to transition people from an old way of doing things to a new way... make that decades when changing from imperial to metric ;)

[jvonau]

Just more dribble, one's believes should not interfere with other's believes, fact of the matter the cmdline overrides all other vars period. Now what was demo'd, skipping failed roles during installation with iiab-install I said could have a place in testing if the value is set, altering iiab-install in the proposed way, trying to skip broken roles becomes an impossibility.

[holta]

With all due respect, designing a community experience (UX) workflow based on Ansible technicalities really is putting the cart in front of the horse.

I think we can elevate this conversation dramatically, but yes it will takes months.

[jvonau]

The entire UX / mental framework / workflow (of things like ./iiab-install and sudo iiab) is built around the notion that "INTERNET-IN-A-BOX (IIAB) SOFTWARE INSTALL IS COMPLETE" is prominently displayed, to confirm to implementer folk that they're over the hump (as Mitra Ardron strongly advocated for — and has helped many people since!)

I'll point out I wrote the initial support for that iiab/iiab-factory@60f6dec

Allowing everyone to set skip_role_on_error: True in /etc/iiab/local_vars.yml and thereby falsely declare victory as soon as they see "INTERNET-IN-A-BOX (IIAB) SOFTWARE INSTALL IS COMPLETE" would create havoc weary

That would be the reason why the default should always be false and the user must place the variable into local_vars to become active or pass a string to override at the cmdline to opt-in to this new behavior. Now with this proposed change to iiab-install, sugarizer installs on ubuntu-22+ will continue failing during iiab-install, thought the whole point of skip_role_on_error was to find failing roles during testing a newer release of a distro. Now I see it as a crutch for admin-console to bypass broken roles selected by the user or forced upon them via the defaults defined in the user selected version of local_vars.yml that the user would otherwise need to turn off.

Quite separately we can create another ./iiab-install-piecewise or ./iiab-install-best-effort (or whatever) as we choose. But this will be a quite different way to skin the cat, evolving forward with a quite different UX

Sure, that is where you could force the value to True to override the default of False, I'm sure cmd-serve could append the same kind of string '--extra-vars {"skip_role_on_error":True to the cmdline call if that is the behavior wanted there and not forcing any other unnecessary changes.

[tim-moody]

That would be the reason why the default should always be false

I'm quite happy with this or it can be left out of default vars altogether, but I suppose that means checks for if def

and the user must place the variable into local_vars to become active

I strongly oppose this.

or pass a string to override at the cmdline

if necessary

[holta]

Certain naive implementers will inevitably expect a magical speed-up by throwing skip_role_on_error: True into /etc/iiac/local_vars.yml without having any clue what they're doing — and then helplessly crying to be rescued when sudo iiab falsely announces "SOFTWARE INSTALL IS COMPLETE" — it will take time, but this fiasco can be avoided until better workflows evolve.

Quite separately we can create another ./iiab-install-piecewise or ./iiab-install-best-effort (or whatever)

So for now this intentionally-quite-hidden option (for hardcore testers, adventure seekers eager to shoot themselves in the foot, etc) is ./iiab-install --risky or ./iiab-install -r for those who want to live on the edge, also forcing iiab-install to run with skip_role_on_error: True

Recap: I don't want to document this prominently, as these things are guaranteed to evolve over time, eventually into something quite significantly better!

sugarizer installs on ubuntu-22+ will continue failing during iiab-install

We should set a time-limit as to how long we're willing to wait for MongoDB to come up with an official install path for Ubuntu 22.04. I'm still leery of investing time in the hacky/temporary workaround of reverting 22.04 from libssl3 to libssl1.1 — but it is an option — e.g. if in coming months Sugarizer folk make themselves heard, and find this absolutely necessary, e.g. on Mint 21 etc:

• MongoDB 4.4, 5.0 & 6.0RC1 don't run on Ubuntu 22.04 (preventing Sugarizer install) [missing apt package libssl1.1 -> libssl3 ?] #3190

At a higher level, whatever eventually replaces ./iiab-install --risky will need to evolve to display errors in a meaningful / actionable way — e.g. that also educates implementers, that might be curious about November 2022's Moodle 4.1 being the projected timeframe for it finally supporting PHP 8.1, ETC:

• Test Moodle 4.0 ETA 2022-04-19, including on Ubuntu 22.04 [with PHP 8.1] #3182

None of this is easy, but we'll get there.

[holta]

At the moment it's very intensively documented that Sugarizer and Moodle do not install on Ubuntu 22.04, e.g. in several places on this page alone: https://github.com/iiab/iiab/wiki/IIAB-8.0-Release-Notes

And also on https://github.com/iiab/iiab/wiki/IIAB-Platforms which clarifies that Ubuntu 22.04 is (unfortunately!) not yet well supported.

But I agree that we need to do better when Mint 21 appears (likely in July or August, based on 22.04) informing novice implementers of their options (in meaningful ways, so they can also learn along the way, about whatever upstream blockages are holding up these 2 apps) as many schools want clarity for September !

e.g. it's just one example, but in the end Moodle chose to drag their feet supporting PHP 8.1 a full year after its release — and a full 2 years after PHP 8.0's release — so finding ways to communicate the latest such tips, re: app compatibility etc, is in fact something schools (and others!) are quite passionate about... definitely a part of the challenge here!

[holta]

@jvonau discussed some of the wider ramifications of variable skip_role_on_error during the 2nd hour of this week's IIAB community call (http://minutes.iiab.io) towards help with MySQL and other things.

Just One Example: it would be wonderful if most/all of IIAB 30-40 apps' Ansible installers (tasks/install.yml generally) could be strengthened to survive power failures / internet failures — i.e. allowing a 2nd attempt at installing (almost every!) IIAB app if the first attempt fails for sundry "operational" reason. Eventually even including roles/pbx possibly, so ideally every tasks/install.yml could be unrolled cleanly in coming years?

Not that IIAB wants to be all-purpose OS for sure, as uninstalling apps after the fact is not a priority. Still: if an increasing number of roles are "audited" to be more failsafe during installation, that would indeed be a real step forward.

[holta]

FYI prior to merging, this PR was tested on Ubuntu 20.04 and 22.04 — and in both ways:

• using the traditional ./iiab-install i.e. with skip_role_on_error: False (overriding default_vars.yml)
• using the experimental ./iiab-install --risky i.e. with skip_role_on_error: True (which happens to be the same as default_vars.yml)

[jvonau]

FYI prior to merging, this PR was tested on Ubuntu 20.04 and 22.04 — and in both ways:

* using the traditional `./iiab-install` i.e. with `skip_role_on_error: False` (overriding default_vars.yml)

What was the result on 22.04 with local_vars_medium.yml? Should of failed with sugarizer. Now with local_vars_large.yml moodle should of failed. Think there is a need to reintroduce a cut down version of #3189

[holta]

What was the result on 22.04 with local_vars_medium.yml? Should of failed with sugarizer.

Yes. Then I ran ./iiab-install --risky to complete the installation of all other "MEDIUM" apps (except for Sugarizer and its MongoDB).

reintroduce a cut down version of #3189

Something like that, yes: my opinion is that we should work towards cleaning up further in time for Mint 21's release later this summer.

Likewise Ubuntu 22.04.1 (likely around early August?) will further legitimize 22.04 (Jammy Jellyfish) as finally being more mainline.

At which point: in-your-face-messaging to IIAB implementers should explain better the latest status of upstream 22.04-related shortcomings like MongoDB and Moodle 4.x — in service to the masses (who of course rarely read README's no matter where they're placed ;-)

[jvonau]

What was the result on 22.04 with local_vars_medium.yml? Should of failed with sugarizer.

Yes. Then I ran ./iiab-install --risky to complete the installation of all other "MEDIUM" apps (except for Sugarizer and its MongoDB).

How would one recover when using the regular curl'd 'iiab' script?

reintroduce a cut down version of #3189

Something like that, yes: my opinion is that we should works towards cleaning up further in time for Mint 21's release later this summer.

How is the release of mint tied to the current situation where medium local_vars fails out of the box on 22.04? It is not the distro failing it is one add-on component from an upstream source that is not ready for 22.04. What is the recommendation don't use ubuntu-22.04 which is a LTS release?

Likewise Ubuntu 22.04.1 (likely around early August?) will further legitimize 22.04 (Jammy Jellyfish) as finally being more mainline.

22.04 is released can't get more mainline than that. 22.10 gets released 2 months later, can you clarify 'being more mainline'?

At which point: in-your-face-messaging to IIAB implementers should explain better the latest status of upstream 22.04-related shortcomings like MongoDB and Moodle 4.x — in service to the masses (who of course rarely read README's no matter where they're placed ;-)

Sure the wait and see if the problem fixes itself before altering/adding documentation makes sense. The hoop dance for current installs on 22.04 seems a bit much. Was that not the original motivation behind #3189, a smooth install until the problem is fixed?

[holta]

How would one recover when using the regular curl'd 'iiab' script?

Excellent question for the future.

This temp patch defers on that larger question for now — making ./iiab-install more manageable for the many newcomers-and-all increasingly moving to Ubuntu 22.04 and Mint 21 Betas in coming weeks/months:

• 22.04 & Mint 21: Avoid Sugarizer+Moodle initially (TEMPORARY) #3265

can you clarify 'being more mainline'?

FWIW Ubuntu will officially recommend upgrades from 20.04 starting around early August when they release 22.04.1 — coincidentally a good time for schools in most countries as they prepare for the coming year!

[jvonau]

How would one recover when using the regular curl'd 'iiab' script?

Excellent question for the future.

Actually the question was intended for today

This temp patch defers on that larger question for now — making ./iiab-install more manageable for the many newcomers-and-all increasingly moving to Ubuntu 22.04 and Mint 21 Betas in coming weeks/months:

* [22.04 & Mint 21: Avoid Sugarizer+Moodle initially (TEMPORARY) #3265](https://github.com/iiab/iiab/pull/3265)

Now I have my answer, actions are clearer than words.

can you clarify 'being more mainline'?

FWIW Ubuntu will officially recommend upgrades from 20.04 starting around early August when they release 22.04.1 — coincidentally a good time for schools in most countries as they prepare for the coming year!

Nothing prevents users making the move now but in reality IIAB relies on a clean install, with updates of the OS applied, as some IIAB apps/services are tied to the underlining libraries with packaging paths changing as a result of being upgraded by the newer distro release.

[holta]

https://ubuntu.com/tutorials/upgrading-ubuntu-desktop#5-optional-upgrading-from-2004-lts-to-2204-lts-early

That spells out Ubuntu upgrading better than in the past, which is very positive.