python3 on el7: 'ERROR! Unexpected Exception, this is probably a bug: SQLite 3.8.3 or later is required (found 3.7.17).'

[dmsimard]

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.

[dmsimard]

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

[juliojsb]

Hi,
So we have to assume that we won't be able to make ARA 1.x work in RHEL7?
Regards,

[flowerysong]

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.

[juliojsb]

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]"

[jstarek]

@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

[dmsimard]

@flowerysong

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.

@juliojsb

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:

• GHSA-hmr4-m2h5-33qx
• GHSA-vfq6-hq5r-27r6

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 ?

[dmsimard]

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/)

[juliojsb]

@dmsimard +1 to the solution you provided, a much better approach!

[dmsimard]

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.