Pre-built image on quay using wrong djangorestframework version

[JossWhittle]

Describe the bug

Related to #266. The pre-built quay.io/vanessa/sregistry image does not seem to have the pinned version of the djangorestframework. Building the image locally is stated as optional in the installation docs but is required to properly execute the management utilities.

To Reproduce

git clone https://github.com/singularityhub/sregistry.git --depth 1 --branch v1.1.31 --single-branch

# Add config.py, secret.py, ect ... 

docker-compose up -d

# Pulls images from quay

NAME=$(docker ps -aqf "name=sregistry_uwsgi_1")
docker exec $NAME python /code/manage.py add_superuser --username somesuperuser

Traceback (most recent call last):
  File "/code/manage.py", line 9, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.5/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.5/site-packages/django/core/management/__init__.py", line 375, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.5/site-packages/django/core/management/base.py", line 323, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python3.5/site-packages/django/core/management/base.py", line 361, in execute
    self.check()
  File "/usr/local/lib/python3.5/site-packages/django/core/management/base.py", line 390, in check
    include_deployment_checks=include_deployment_checks,
  File "/usr/local/lib/python3.5/site-packages/django/core/management/base.py", line 377, in _run_checks
    return checks.run_checks(**kwargs)
  File "/usr/local/lib/python3.5/site-packages/django/core/checks/registry.py", line 72, in run_checks
    new_errors = check(app_configs=app_configs)
  File "/usr/local/lib/python3.5/site-packages/django/core/checks/urls.py", line 13, in check_url_config
    return check_resolver(resolver)
  File "/usr/local/lib/python3.5/site-packages/django/core/checks/urls.py", line 23, in check_resolver
    return check_method()
  File "/usr/local/lib/python3.5/site-packages/django/urls/resolvers.py", line 399, in check
    for pattern in self.url_patterns:
  File "/usr/local/lib/python3.5/site-packages/django/utils/functional.py", line 80, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/usr/local/lib/python3.5/site-packages/django/urls/resolvers.py", line 584, in url_patterns
    patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
  File "/usr/local/lib/python3.5/site-packages/django/utils/functional.py", line 80, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/usr/local/lib/python3.5/site-packages/django/urls/resolvers.py", line 577, in urlconf_module
    return import_module(self.urlconf_name)
  File "/usr/local/lib/python3.5/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 985, in _gcd_import
  File "<frozen importlib._bootstrap>", line 968, in _find_and_load
  File "<frozen importlib._bootstrap>", line 957, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 697, in exec_module
  File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
  File "/code/shub/urls.py", line 17, in <module>
    from shub.apps.api import urls as api_urls
  File "/code/shub/apps/api/urls/__init__.py", line 2, in <module>
    from .routers import urlpatterns as routers
  File "/code/shub/apps/api/urls/routers.py", line 21, in <module>
    router.register(r"^containers", ContainerViewSet, base_name="container")
TypeError: register() got an unexpected keyword argument 'base_name'

Expected behavior

docker-compose down

docker build -t quay.io/vanessa/sregistry .

docker-compose up -d

NAME=$(docker ps -aqf "name=sregistry_uwsgi_1")
docker exec $NAME python /code/manage.py add_superuser --username somesuperuser

# Succeeds!

[vsoch]

huh, that definitely is strange - the containers are deployed with an automated build on merge, and according to the registry the last build was 20 days ago. Could you compare the working version of Django against what was built here? https://app.circleci.com/pipelines/github/singularityhub/sregistry/147/workflows/9e08f383-cf67-44ce-9b4f-97cbcaa06035/jobs/1285. If there is an issue there then it must be that the older version is being cached, or something like that.

[JossWhittle]

So the version pulled from quay does actually have the advertised version 3.11.2 of djangorestframework but also has the error related to the base_name parameter. Building locally actually results in an earlier version 3.10.3 than is pinned.

docker-compose up -d

# Pulls images from quay

NAME=$(docker ps -aqf "name=sregistry_uwsgi_1")
docker exec $NAME pip list | grep djangorestframework

Yields:

djangorestframework        3.11.2

---

docker-compose down

docker build -t quay.io/vanessa/sregistry .

docker-compose up -d

NAME=$(docker ps -aqf "name=sregistry_uwsgi_1")
docker exec $NAME pip list | grep djangorestframework

Yields:

djangorestframework        3.10.3

[vsoch]

I'm afraid I can't reproduce that - building locally I get 3.11.2.

$ docker run --rm -it quay.io/vanessa/sregistry:latest bash
root@2c68e1f0c442:/code# pip freeze | grep djangorest
DEPRECATION: Python 3.5 reached the end of its life on September 13th, 2020. Please upgrade your Python as Python 3.5 is no longer maintained. pip 21.0 will drop support for Python 3.5 in January 2021. pip 21.0 will remove support for this functionality.
djangorestframework==3.11.2

I think the issue is that we missed one base_name:

router.register(r"^build", views.RecipePushViewSet, base_name="build")  # build

I'm not sure why you are building and getting an older version (maybe a cache?) but what I can do is a PR to fix this bug, and then also bump the python version in the container (3.5 is EOL). This is a non work related project, so I'll have this for you at the end of the day to test. Thanks for reporting!

[JossWhittle]

Having a closer look the the version difference is because requirements.txt was updated after the last (v1.1.31) release.

https://github.com/singularityhub/sregistry/blame/v1.1.31/requirements.txt#L22

https://github.com/singularityhub/sregistry/blame/master/requirements.txt#L22

I re-cloned on master and now a locally built image has the correct 3.11.2 version as you'd expect but there is naturally the issue with base_name.

The confuser I think has been due to docker-compose pulling whichever the :latest image is when it needs to be the matching tagged release image when you clone a release tag or download the zipped bundle.

[vsoch]

That would make sense, it's sort of assumed that the user will just clone master, but if the clone is to a release, the release should use the matching tag. I can use this convention going forward.

[vsoch]

@JossWhittle please see https://github.com/singularityhub/sregistry/pull/363. Instead of pinning versions in the docker-compose (which is hard to maintain) I added a section to the docs, and comments alongside the image names. When you get a chance could you please test? When we merge that PR there will be a container build and deploy to quay, and I can also draft a release here.

[JossWhittle]

@vsoch sorry for the delayed response. All working now by modifying the docker-compose to use the correct images. Thank you for the assistance in debugging.

[vsoch]

Sure thing! So the bump in Python in the base images is A-ok?

[vsoch]

Ping @JossWhittle did you get a chance to review the PR for this issue?

[JossWhittle]

The PR branch spins up correctly through docker-compose using the new python version, but this isn't a test using a fully configured installation.

I'm still using v1.1.31 in production currently by changing the compose file for version pinning and adding traefik for SSL.