Interim/Alternative to PR #2742 accelerates testing w/ "pip3 install ansible-core" (2.11+) in both places

[holta]

Refs: PR #2689, #2721, PR #2742

[holta]

Testing of this PR (for PR #2742, to be merged in a week) is looking good during a BIG-sized IIAB install onto Ubuntu Server 20.10 on RPi 4 (10.8.0.66) using:

curl d.iiab.io/install.txt | bash -s 2743

(It's currently wrapping up Stage 8 of 9, as it runs through iiab-install.)

[holta]

CLARIF: this PR will likely be closed (and not merged) after PR #2742 is merged on/around 2021-04-26.

Until that time, this PR #2743 is however extremely useful for testing IIAB installs, with the new ansible-core 2.11 RC2 etc.

[holta]

This PR was never intended to be permanent. But if Ansible "refuses" to release the PPA (.deb files) for ansible-core 2.11 as discussed on PR #2742, then this approach (based on pip3 install ansible-core) certainly works very well and might be considered instead.

(As evidenced by this PR #2743 having been tested rock solid on many different VM's and RPi 4's over the last couple weeks!)

[holta]

@deldesir & All: let's take this approach (pip3 install ansible-core) more seriously as Ansible / Red Hat / IBM are clearly de-prioritizing PPA (.deb file installers) on purpose, ~2 months after ansible-core release candidates were widely circulated, and ~1 month after ansible-core's 2.11.0 official release.

[holta]

This PR was installed with a fresh BIG-sized IIAB install onto Ubuntu Server 20.04 VM 192.168.0.191 = 10.8.0.50 :

curl d.iiab.io/install.txt | sudo bash -s 2743

Let's go with it on an interim/experimental basis to broaden community-testing of IIAB with ansible-core 2.11

[holta]

Hopefully this PR will also materially speed up...the very regular Travis-CI checks of IIAB's Ansible syntax etc.

(And possibly speed up the early part of IIAB installs just a bit as well?)

[holta]

Quite separate from the speedups and dramatic simplification associated with pip3 install ansible-core this whole saga might be a blessing in disguise — if it gets IIAB out of the business of constantly fussing with Ansible's ever-changing PPA installation complexities and particulars?

To focus on learning/content instead, where we're urgently needed.

(Instead of yet another 1st World Problem ;)

[holta]

FYI pastes below occurred after pip3 install ansible-core was run on Ubuntu Server 20.04 = 10.8.0.50 — as discussed on IIAB weekly call (http://minutes.iiab.io) earlier today:

root@box:/usr/local/bin# ls
ansible             ansible-doc        ansible-pull   speedtest-cli
ansible-config      ansible-galaxy     ansible-test
ansible-connection  ansible-inventory  ansible-vault
ansible-console     ansible-playbook   speedtest

root@box:/usr/local/lib/python3.8/dist-packages# du -hsc ansible*
11M     ansible
176K    ansible_core-2.11.0.dist-info
3.0M    ansible_test
14M     total

root@box:/usr/local/lib/python3.8/dist-packages# ls -l ansible_core-2.11.0.dist-info/
total 172
-rw-r--r-- 1 root staff  35148 May 19 11:11 COPYING
-rw-r--r-- 1 root staff      4 May 19 11:11 INSTALLER
-rw-r--r-- 1 root staff   7643 May 19 11:11 METADATA
-rw-r--r-- 1 root staff 117479 May 19 11:11 RECORD
-rw-r--r-- 1 root staff     21 May 19 11:11 top_level.txt
-rw-r--r-- 1 root staff     92 May 19 11:11 WHEEL

root@box:/usr/local/lib/python3.8/dist-packages# cat ansible_core-2.11.0.dist-info/WHEEL
Wheel-Version: 1.0
Generator: bdist_wheel (0.34.2)
Root-Is-Purelib: true
Tag: py3-none-any

root@box:/usr/local/lib/python3.8/dist-packages# ls ansible/
cli          constants.py  galaxy            modules       plugins      utils
collections  context.py    __init__.py       module_utils  __pycache__  vars
compat       errors        inventory         parsing       release.py   _vendor
config       executor      keyword_desc.yml  playbook      template

root@box:/usr/local/lib/python3.8/dist-packages# ls ansible_test/
config  data  _init__.py  internal  _pycache__