Project

Profile

Help

Issue #7493

Installer: remove auth migration task

Added by chouseknecht about 1 month ago. Updated about 19 hours ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
-
Category:
Installer
Sprint/Milestone:
Start date:
Due date:
Estimated time:
Severity:
3. High
Version:
Platform Release:
OS:
Triaged:
No
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:

Description

Currently the installer runs auth migrations first, then runs all other migrations. This is causing the following error in galaxy_ng:

TASK [pulp_database_config : Run database auth migrations] *********************
fatal: [pulp3-source-fedora31]: FAILED! => {
    "changed": true,
    "cmd": [
        "/usr/local/lib/pulp/bin/django-admin",
        "migrate",
        "auth",
        "--no-input"
    ],
    "delta": "0:00:04.244303",
    "end": "2020-09-10 20:49:05.957899",
    "rc": 1,
    "start": "2020-09-10 20:49:01.713596"
}

STDOUT:

Operations to perform:
  Apply all migrations: auth
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0001_initial... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK


STDERR:

Traceback (most recent call last):
  File "/usr/local/lib/pulp/lib64/python3.7/site-packages/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
psycopg2.errors.UndefinedTable: relation "galaxy_user" does not exist
LINE 1: ...er"."is_active", "galaxy_user"."date_joined" FROM "galaxy_us...

Django's migration system should get it right (i.e., run things in the correct order) no matter what. If it isn't, it's because a dependency isn't in place correctly in the code that declares migration dependencies.

According to bmbouter, "Early on in pulp3 there was a requirement for it to be run in two-steps because we weren't commiting migrations to git. Like years ago at this point. I think this is a vestige from that."


Related issues

Related to Pulp - Issue #7499: pulp_installer is unpredictable about when it resets the admin passwordCLOSED - CURRENTRELEASE<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

Associated revisions

Revision 0a0c3bbc View on GitHub
Added by chouseknecht about 1 month ago

Allow auth migrations to work when installing galaxy_ng

fixes: #7493

Revision 0a0c3bbc View on GitHub
Added by chouseknecht about 1 month ago

Allow auth migrations to work when installing galaxy_ng

fixes: #7493

Revision 187493e1 View on GitHub
Added by Mike DePaulo about 1 month ago

Fix auth migrations being run for galaxy_ng.

Due to code removal, the pulp_default_admin_password is now set whenever pulpcore is 1st installed, updated/upgraded, or when pulp_upgraded_manually==true.

Also do 1 fix & 1 improvement for determining whether or not pulpcore was installed/upgraded.

We decided against modifying the auth migration task to not create the django-guardian anonymous user; a change in advertently introduced in 3.6.0. Doing so would have fixed migrations for galaxy_ng with fewer changes. However we want the anonymous user to get created, to help make Pulp installs consistent, whether pulp_installer 3.6.0 through 3.6.3 was run or whether future versions of it get run.

fixes: #7493

Revision 187493e1 View on GitHub
Added by Mike DePaulo about 1 month ago

Fix auth migrations being run for galaxy_ng.

Due to code removal, the pulp_default_admin_password is now set whenever pulpcore is 1st installed, updated/upgraded, or when pulp_upgraded_manually==true.

Also do 1 fix & 1 improvement for determining whether or not pulpcore was installed/upgraded.

We decided against modifying the auth migration task to not create the django-guardian anonymous user; a change in advertently introduced in 3.6.0. Doing so would have fixed migrations for galaxy_ng with fewer changes. However we want the anonymous user to get created, to help make Pulp installs consistent, whether pulp_installer 3.6.0 through 3.6.3 was run or whether future versions of it get run.

fixes: #7493

History

#1 Updated by mdepaulo@redhat.com about 1 month ago

  • Related to Issue #7499: pulp_installer is unpredictable about when it resets the admin password added

#2 Updated by osapryki about 1 month ago

The issue is caused by the post migration hook installed by the django-guardian package. The hook attempts to create an anonymous user. However since the user table is not a part of the django.contrib.auth application and is not available after applying auth migrations subset, the hook fails.

From django-guardian package code it appears that the post migration hook is controlled by the ANONYMOUS_USER_NAME settings parameter. If no ANONYMOUS_USER_NAME is set, it is set by default to AnonymousUser in settings.py#L13.

As a workaround for this situation, creation of anonymous user can be disabled while applying auth migrations:

$ PULP_ANONYMOUS_USER_NAME='@none None' django-admin manage migrate --no-input auth

#4 Updated by pulpbot about 1 month ago

  • Status changed from NEW to POST

#5 Updated by chouseknecht about 1 month ago

  • Status changed from POST to MODIFIED

#6 Updated by ttereshc 2 days ago

  • Sprint/Milestone set to 3.8.0

#7 Updated by ttereshc about 19 hours ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF