python3 on el7: 'ERROR! Unexpected Exception, this is probably a bug: SQLite 3.8.3 or later is required (found 3.7.17).'
dmsimard opened this issue · comments
What component is this about ?
django's sqlite database backend
What is your ARA installation like ?
python3 virtualenv on el7 with default settings: offline api client and sqlite database backend
What is happening ?
Before attempting sqlite migrations, django fails with the following error:
'ERROR! Unexpected Exception, this is probably a bug: SQLite 3.8.3 or later is required (found 3.7.17).'
What should be happening ?
It would be nice for the default use case to work on el7.
I haven't yet investigated this issue.
It doesn't look like we can expect the base sqlite included in EL7 to be updated beyond 3.7.17 based on the package history: https://git.centos.org/rpms/sqlite/commits/c7
Hi,
So we have to assume that we won't be able to make ARA 1.x work in RHEL7?
Regards,
ARA doesn't directly depend on a newer version of SQLite, the version requirement is imposed by Django. If you install django<2.2 instead of the latest then ARA (currently) works fine.
Thanks, just in case someone needs it, this is how to make the last version of ARA 1.x work in CentOS/RHEL 7.x
pip3 install --user Django==2.1.15
pip3 install --user "ara[server]"
@juliojsb, many thanks for that suggestion! However, it just leads me into a situation where the ara callback is skipped due to
[WARNING]: Skipping plugin (/home/vm/.local/lib/python3.6/site-packages/ara/plugins/callback/ara_default.py) as it seems to be invalid: No module named ara.clients
ARA doesn't directly depend on a newer version of SQLite, the version requirement is imposed by Django. If you install django<2.2 instead of the latest then ARA (currently) works fine.
Thanks, just in case someone needs it, this is how to make the last version of ARA 1.x work in CentOS/RHEL 7.x
pip3 install --user Django==2.1.15 pip3 install --user "ara[server]"
and @jstarek,
I can't recommend or support doing this because of documented django CVEs like these:
Generally speaking, you want to keep django as up to date as possible to get those security fixes.
What I would recommend for running the API server on CentOS 7 would be to use podman (docker) containers. It's three commands, built into CentOS distribution and no daemon or service to run:
yum -y install podman
mkdir -p ~/.ara/server
podman run --name ara-api --detach --tty \
--volume ~/.ara/server:/opt/ara:z \
-p 8000:8000 \
docker.io/recordsansible/ara-api:pypi-latest
Then, on your host:
# No need for the ``[server]`` prefix, we don't need API server dependencies
pip3 install ara
export ANSIBLE_CALLBACK_PLUGINs=$(python3 -m ara.setup.callback_plugins)
export ARA_API_CLIENT=http
export ARA_API_SERVER=http://127.0.0.1:8000
I'm happy to put this in the documentation -- you can read more about how you can build your own images and how to run them: https://ara.readthedocs.io/en/latest/container-images.html
The images on DockerHub ( https://hub.docker.com/r/recordsansible/ara-api ) are currently based on Fedora but there is a pull request for one based on CentOS 8: #133
I feel it would be a good alternative that would be less hacky, more secure and easier to support. What do you think ?
Re: django version, we're currently targetting 2.2 which is a LTS release and this makes it much easier to support from a packaging perspective. There is no incentive to upgrade to 3.x yet.
(Source: https://www.djangoproject.com/download/)
I've sent a patch to refresh the installation docs and it'll contain a note about this issue with a recommendation to use container images for running the API server on CenOS 7:
I believe we'll be good to close this issue once the patch lands and the docs are updated.