search

jcalazan / ansible-django-stack

Ansible Playbook for setting up a Django app with Nginx, Gunicorn, PostgreSQL, Celery, RabbitMQ, Supervisor, Virtualenv, and Memcached. A Vagrantfile for provisioning a VirtualBox virtual machine is included as well.
MIT License
1.37k stars 391 forks source link

Control PostgreSQL installed version with 'db_version' variable #169

Open jpmjpmjpm opened 4 years ago

jpmjpmjpm commented 4 years ago

Version 12 is used in the playbook Closes #168 Note: PostgreSQL version is managed with 'db_version' variable. However, there is no DB upgrade process with DB previous code deletion, DB stopped and restarted. This is not an issue compared to playbook version without this commit though.

YPCrumble commented 4 years ago

@jpmjpmjpm Thank you for the PR!!! A couple quick questions:

So I understand, is your comment saying that increasing the db version will not upgrade PSQL in the way it should be upgraded? If so would you make a comment saying that above the db_version variable?

Also - if we put in 12 does this automatically install the latest version (e.g., 12.4)? Or does it install 12.0? I believe it would install 12.4, just checking. In that case perhaps we should specify the minor version as well - otherwise this would install 12.0, 12.1, 12.2, etc. as they're made available?

jpmjpmjpm commented 4 years ago

@YPCrumble I made a test and the PR indeed installs PostgreSQL 12.4 (latest 12 minor version) on a 'brand new server' . Which is good!

What I don't know is what happens if you already have an existing previous minor version installed, let say 12.3. I suspect that 12.4 will be installed but I don't know if it will supersede 12.3. Such a test seems not easy to perform as I haven't find (based on quick Google search) a way to install an older minor version than the current one.

However, the PR is better than current version of the playbook, as current version installs version 13 and starts it without it being used by the application.

Note: the playbook (with or without the PR) can't be used to upgrade DB data between major versions (i.e. 12 to 13). For that this post is of interest. I imagine this was clear, but better to precise it!

YPCrumble commented 4 years ago

@jpmjpmjpm to avoid any potential issues, what do you think about specifying 12.4 as the version? That will also ensure that users are aware they can specify a precise minor version if they want. That would work, right?

jpmjpmjpm commented 4 years ago

@jpmjpmjpm to avoid any potential issues, what do you think about specifying 12.4 as the version? That will also ensure that users are aware they can specify a precise minor version if they want. That would work, right?

@YPCrumble I was looking to do so, but I don't think this is an easy process. Replacing db_version: 12 with db_version: 12.4 doesn't work. By the way googling for information, I saw that installing a minor version which is not the last one needs to build that minor version from PostgreSQL sources. Not sure that we should look in that direction.

The PR I propose may not be the best as I don't know how it will proceed in term of minor version upgrades. However, it is still an improvement compared to current version which installs a new major version on top of a previous one and starts it in parallel. I also noticed in my case that the running version for the application is still 12.4, that 13 is installed and that the psql version used is 13 connected to 12.4!

For a subsequent PR, I was looking at PostgreSQL minor version upgrade post.

On my side, I uninstalled 13 and everything went fine. To be used with caution though I imagine!