-
Notifications
You must be signed in to change notification settings - Fork 847
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
Update Docker Image to Ubuntu 24.04 ( Noble ) #2739
base: develop
Are you sure you want to change the base?
Update Docker Image to Ubuntu 24.04 ( Noble ) #2739
Conversation
- wildcard
…-Vagrants/develop v3.11 PR
…-Vagrants/develop 3.11.2 on stable
…-Vagrants/develop 3.12 stable
…-Vagrants/develop v3.1.2 stable
# Conflicts: # provision/core/git/provision.sh
- Add OVH url in hosts_to_test ( keep the mariadb.gb.ssimn.org )
- Better messages
Thanks for opening this pull request! Make sure
|
@pentatonicfunk how much of this can we split into separate PRs? Upgrading Ubuntu isn't a small task but adding the sources could be done and released pretty quickly to simplfy merging. Likewise some of the other changes are useful and quick to test on their own. I am mindful that upgrading Ubuntu the last time resulted in some weirdness that needed investigation. Also, the service changes, I was thinking of changing how services are restarted to use a VVV specific function to insulate against |
i will try to cherry picks into separate branches next week. |
@@ -480,7 +480,7 @@ Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| | |||
|
|||
# Docker use image. | |||
config.vm.provider :docker do |d, override| | |||
d.image = 'pentatonicfunk/vagrant-ubuntu-base-images:20.04' | |||
d.image = 'pentatonicfunk/vagrant-ubuntu-base-images:24.04' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this trigger a VM rebuild for exsting Ubuntu 22 instances that upgrade?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good question, i dont know. it would be vagrant territory, no ? the decision whether docker container need rebuild or not would be based on what vagrant flow will be issued. in any case better to test it, i'll try to test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
main concerns is if vagrant would kick up a fuss about mismatching images or if it would discard the container ( and the database + data ) to create a new 24 container
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so i tested this, this is how i tested it
use upstream/develop
branch
- Vagrantfile still using 20.04 image
- do
vagrant up --provision
- verify ubuntu version via
vagarant ssh
vagrant@vvv:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
- create new post in one.wordpress.test to verify DB okay
switch to origin/docker-provider
- Vagrantfile now 24.4
- do
vagrant halt
to stop docker - do
vagrant reload --provision
to trigger reprovision - verify ubuntu version via
vagarant ssh
, expecting the Ubuntu should stay in 20.04
Last login: Fri Nov 15 15:33:51 2024 from 172.17.0.1
vagrant@vvv:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
- verify whether DB not discarded ( post still exists )
i think this is what we expected, right ?
- no complains on provisioner
- container not discarded
- DB not discarded
i think what we can do is, add somewhere in docs ( if we haven't), if user wants to upgrade their OS is by doing
db_backup
vagrant destroy
vagrant up --provision
--> this step will trigger 24.04db_restore
provision/core/vvv/provision.sh
Outdated
sudo pip3 install wheel | ||
sudo pip3 install shyaml | ||
|
||
local OSVERSION_NUMBER=$(lsb_release lsb_release -sr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shellcheck will probably flag this and a few other things, it should be something like this:
local OSVERSION_NUMBER=$(lsb_release lsb_release -sr) | |
local OSVERSION_NUMBER | |
OSVERSION_NUMBER=$(lsb_release lsb_release -sr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
adjusted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
huh, this adjustments causing error for some reason
lsb_release: error: No arguments are permitted
https://github.com/Varying-Vagrant-Vagrants/VVV/actions/runs/11580749924/job/32239965581?pr=2739
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reverted it to the original changes. the checks / linting seems to be fine: https://github.com/Varying-Vagrant-Vagrants/VVV/actions/runs/11581054132/job/32240928199?pr=2739
and we already doing these kind of local syntax previously: https://github.com/Varying-Vagrant-Vagrants/VVV/blob/develop/provision/core/vvv/provision.sh#L62-L64
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah I think the problem is a mistake on my part, lsb_release
vs lsb_release lsb_release
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
adjusted, and seems to be ran okay: https://github.com/Varying-Vagrant-Vagrants/VVV/actions/runs/11858839047/job/33050382482?pr=2739
let me know if it needs further adjustments
if dpkg --compare-versions "${OSVERSION_NUMBER[@]}" ge "24.04" | ||
then | ||
# to make it available globally this is the last workaround, hopefully it doesn't break the system | ||
# TODO: try to find a better alternative way to install |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there somewhere I can read up on why this happens or where the fix came from? Would be good to have it in the comments, I've created a separate PR for shyaml fixes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Tom J Nowell <[email protected]>
This reverts commit c705505.
This reverts commit 87ba465.
This reverts commit c798cef.
This reverts commit 30b8230.
This reverts commit bbcf60d.
This reverts commit 4c38733.
…beta # Conflicts: # provision/provision-helpers.sh
…r-provider # Conflicts: # provision/core/mariadb/provision.sh
This reverts commit 3e6aec5.
-- Add missing
noble
repository list-- Hacky fix of pip shyaml install on Ubuntu 24.04: see https://pimylifeup.com/python-externally-managed-environment/
vvv_get_mysql_service_name
, in attempt to improvemariadb
vsmysql
service inconsistency-- Unable to replicate the service name inconsistency, but it happened. ref: Slack #docker
general.php_cli_version
-- It does have use case for me personally at least
-- Generally this provides user with better control of PHP CLI version rather than meddling / replicating
vvv_restore_php_default
to change PHP CLI version: https://github.com/Varying-Vagrant-Vagrants/varyingvagrantvagrants.org/blob/main/docs/en-US/adding-a-new-site/changing-php-version.md?plain=1#L83Checks
develop
branch not thestable
branch.Note on testing:
Changelogs: