On Thu, 14 Nov 2019 12:31:33 +0000 Steve Kersley steve.kersley@keble.ox.ac.uk wrote:
Afternoon all,
Is there a way to downgrade a Nav install to 4.9.8? Or will I need to blow away the database and start from scratch (no huge deal to be honest).
Unfortunately, upgrading the database schema is irreversible.
Confession: I'm running it on Ubuntu rather than the recommended Debian. It got upgraded to 5.0.0, but as the Ubuntu LTS releases don't have a version of graphite-web that works with wsgi-python3 it's become an either/or, and I use graphite for storing other metrics as well as those from Nav. On attempting to pin the older version of Nav, it's failing to install because the database update script failed. Which I presume is because it had already upgraded the database for 5.0.0.
We actually deploy neither NAV nor graphite-web using mod_wsgi in production; we use uwsgi for both. That experience really came in handy when the virtual appliance was rebuilt on Debian Buster, which features a graphite-web package that runs on Python 3, while NAV was still running on Python 2 at the time.
At the moment, the virtual appliance still runs NAV in mod_wsgi, but runs graphite-web using uwsgi (in production, we run both in separate uwsgi processes). The upshot is that they can run on separate versions of Python.
You may be able to draw inspiration from the appliance to run your graphite-web in uwsgi - then the Python version differences shouldn't matter.
The config bits specific to deploying uwsgi and proxying Apache to that can be seen on the navappliance Github repo [1] - these set up an Apache virtual host for graphite-web, and a uwsgi process that Apache forwards its requests to. The only difference for you would be that the `plugins` option in the uwsgi application config should be `python` for Python 2 (where the appliance uses `python3`), and, of course, the `touch-reload` patch should be changed appropriately.
I'm also toying after this to look at options of having Nav (and graphite and other services on this machine) as Docker containers simply to avoid version clashes in future. I see that Docker is listed as experimental, are there any particular issues to be aware of?
It's experimental as in "we have no experience with running this container-based setup in a production environment yet". The main issue I have with it, at the moment, is that the individual NAV processes aren't containerized separately. They should be, in order to properly externalize both process control and log handling. In the current version of [2], the logs are still saved to the file system by the NAV processes, but at least they are on a dedicated Docker volume.
However, we will happily accept pull requests that improve the current state of the containerized version, if you want to go down that route. I already have another guy on IRC that has submitted some PRs to that repo, and who appears to be using it in production.
[1] https://github.com/Uninett/navappliance/blob/68592692de240cddf0b4929c882521d... [2] https://github.com/Uninett/nav-container/