Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamically extract python_ver & postgresql_version #3438

Merged
merged 3 commits into from
Dec 21, 2022

Conversation

holta
Copy link
Member

@holta holta commented Dec 21, 2022

To end the hard-coding of both variables, which were not only bureaucratic but also problematic in certain situations, e.g. as pre-release OS's like Debian 12 Bookworm and Ubuntu 23.04 Lunar Lobster evolve:

  • Python version had both been hard-coded (with Ansible, for Lokole template) and dynamically-extracted (using shell call-out python3 itself) e.g. by Lokole. This rather sloppy approach (violating SSOT, IIAB has been using 2 different potentially contradictory variables python_ver and python_version) is put to an end, in favor of dynamically-extracting IIAB's Python 3 version, uniformly across the board.

  • PostgresSQL version (postgresql_version) hard-coding is likewise removed, but unlike above, this is fully contained within its tasks/install.yml

  • PHP version (php_version) possibly could be dynamically-extracted in future to further simplify (and make IIAB installs yet more resilient) but this PR opts to leave that untouched.

  • Ubuntu 20.04 is more fully desupported after almost 3 years, finally.

This PR is tested on the latest Ubuntu 23.04

Refs:

@holta holta added this to the 8.0 milestone Dec 21, 2022
@tim-moody
Copy link
Contributor

assumes no venv?

@holta
Copy link
Member Author

holta commented Dec 21, 2022

assumes no venv?

This PR doesn't change any assumptions regarding IIAB's current venv / virtualenv virtual environments.

(If things are installed in a venv, global IIAB/Ansible variable python_ver can be ignored if one chooses a different version of Python there.)

PS This PR formally makes Python 3 a requirement for IIAB, as explained here:

https://github.com/holta/iiab/blob/b691bd8252a67205f6c6f4c7660fc7c18153b780/scripts/local_facts.fact#L128-L133

@holta
Copy link
Member Author

holta commented Dec 21, 2022

  • PHP version (php_version) possibly could be dynamically-extracted in future to further simplify (and make IIAB installs yet more resilient) but this PR opts to leave that untouched.

FYI this will be done in a separate PR.

Possibly by parsing the output of apt list php — so that this works regardless of whether PHP is already installed or not.

@holta
Copy link
Member Author

holta commented Dec 21, 2022

Looks good. Merging to broaden community testing.

Dynamic extraction of PHP version can follow at a later date — to make IIAB installs even more resilient a.k.a. antifragile.

@holta
Copy link
Member Author

holta commented Dec 21, 2022

Also successfully tested with a LARGE-sized IIAB install onto Ubuntu Server 22.04

Copy link
Contributor

@deldesir deldesir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed.

Copy link
Contributor

@deldesir deldesir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed

@deldesir
Copy link
Contributor

Reviewed them. Ignore my previous confusion (thought I was on 3439)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants