Issue #7493
closedInstaller: remove auth migration task
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
Updated by mdepaulo@redhat.com about 4 years ago
- Related to Issue #7499: pulp_installer is unpredictable about when it resets the admin password added
Updated by osapryki about 4 years 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
Updated by rchan about 4 years ago
Added by chouseknecht about 4 years ago
Added by chouseknecht about 4 years ago
Revision 0a0c3bbc | View on GitHub
Allow auth migrations to work when installing galaxy_ng
fixes: #7493
Updated by pulpbot about 4 years ago
- Status changed from NEW to POST
Updated by chouseknecht about 4 years ago
- Status changed from POST to MODIFIED
Applied in changeset ansible-pulp|0a0c3bbc5ad904e0cc0d0532136a565fcd0f30d1.
Added by Mike DePaulo about 4 years ago
Revision 187493e1 | View on GitHub
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
Added by Mike DePaulo about 4 years ago
Revision 187493e1 | View on GitHub
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
Updated by ttereshc about 4 years ago
- Status changed from MODIFIED to CLOSED - CURRENTRELEASE
Allow auth migrations to work when installing galaxy_ng
fixes: #7493