Project

Profile

Help

Issue #4545

pulp fails to install on centos7

Added by jsherril@redhat.com 7 months ago. Updated 5 months ago.

Status:
MODIFIED
Priority:
High
Category:
-
Sprint/Milestone:
Start date:
Due date:
Severity:
2. Medium
Version:
Platform Release:
Blocks Release:
OS:
Backwards Incompatible:
No
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Katello-P2
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:
Sprint 54

Description

vagrant up pulp3-source-centos7


Operations to perform:
  Apply all migrations: admin, auth, contenttypes, core, file, sessions
Running migrations:
  Applying core.0004_auto_20190314_1604...

STDERR:

Traceback (most recent call last):
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute
    return self.cursor.execute(sql, params)
psycopg2.ProgrammingError: syntax error at or near "WITH ORDINALITY" 
LINE 6:                     FROM unnest(c.conkey) WITH ORDINALITY co...
                                                  ^

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/pulp/bin/pulp-manager", line 11, in <module>
    load_entry_point('pulpcore', 'console_scripts', 'pulp-manager')()
  File "/home/vagrant/devel/pulp/pulpcore/app/entry_points.py", line 11, in pulp_manager_entry_point
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/core/management/__init__.py", line 375, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/core/management/base.py", line 316, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/core/management/base.py", line 353, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/core/management/base.py", line 83, in wrapped
    res = handle_func(*args, **kwargs)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/core/management/commands/migrate.py", line 203, in handle
    fake_initial=fake_initial,
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/migrations/executor.py", line 117, in migrate
    state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/migrations/executor.py", line 147, in _migrate_all_forwards
    state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/migrations/executor.py", line 244, in apply_migration
    state = migration.apply(state, schema_editor)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/migrations/migration.py", line 124, in apply
    operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/migrations/operations/fields.py", line 216, in database_forwards
    schema_editor.alter_field(from_model, from_field, to_field)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/backends/base/schema.py", line 523, in alter_field
    old_db_params, new_db_params, strict)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/backends/postgresql/schema.py", line 122, in _alter_field
    new_db_params, strict,
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/backends/base/schema.py", line 531, in _alter_field
    fk_names = self._constraint_names(model, [old_field.column], foreign_key=True)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/backends/base/schema.py", line 1029, in _constraint_names
    constraints = self.connection.introspection.get_constraints(cursor, model._meta.db_table)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/backends/postgresql/introspection.py", line 158, in get_constraints
    """, ["public", table_name])
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/backends/utils.py", line 68, in execute
    return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/backends/utils.py", line 77, in _execute_with_wrappers
    return executor(sql, params, many, context)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute
    return self.cursor.execute(sql, params)
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/utils.py", line 89, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/usr/local/lib/pulp/lib64/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute
    return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: syntax error at or near "WITH ORDINALITY" 
LINE 6:                     FROM unnest(c.conkey) WITH ORDINALITY co...

Related issues

Blocked by Pulp - Task #4450: remove pulp-manager MODIFIED Actions
Blocks Pulp - Story #4487: As a user, I can spin up Pulp in a FIPS enabled environment with pulplift MODIFIED Actions

Associated revisions

Revision 916ad2da View on GitHub
Added by amacdona@redhat.com 5 months ago

Add workon/virtualenvwrapper to centos

Whatever was causing the installation problem seems to have gone away,
leaving only a minor problem that virtualenvwrapper is not installed on
CentOS so `workon pulp` didn't work.

https://pulp.plan.io/issues/4545
fixes #4545

History

#1 Updated by amacdona@redhat.com 7 months ago

Are you using any custom ansible variables? Could you post them here?

I'm surprised to see this show up now unless you are setting pulp_install_postgresql to false and using an old version already installed.

#2 Updated by amacdona@redhat.com 7 months ago

  • Triaged changed from No to Yes
  • Sprint set to Sprint 50

#3 Updated by jsherril@redhat.com 7 months ago

Nope, this should be seen with just a 'vagrant up pulp3-sandbox-centos7'

#4 Updated by jsherril@redhat.com 7 months ago

Errr not sandbox, 'pulp3-source-centos7'

#5 Updated by amacdona@redhat.com 7 months ago

I can confirm that this is a problem using the vanilla settings. This may be a result of the difference between the containers we use for pulplift vs the containers that molecule uses to test against Centos7.

Also, I'm adding a blocking relationship with #4450 (https://github.com/pulp/ansible-pulp3/pull/91)

#6 Updated by amacdona@redhat.com 7 months ago

  • Blocked by Task #4450: remove pulp-manager added

#7 Updated by rchan 7 months ago

  • Sprint changed from Sprint 50 to Sprint 51

#8 Updated by dalley 6 months ago

  • Tags Pulp 3, Pulp 3 installer added

#9 Updated by daviddavis 6 months ago

  • Blocks Story #4487: As a user, I can spin up Pulp in a FIPS enabled environment with pulplift added

#10 Updated by rchan 6 months ago

  • Sprint changed from Sprint 51 to Sprint 52

#11 Updated by bmbouter 6 months ago

  • Tags deleted (Pulp 3)

#12 Updated by daviddavis 6 months ago

  • Subject changed from pulp fails to install on centos7 (postgresql 9.2) to pulp fails to install on centos7

When I spin up pulp3-source-centos7, the provisioning seems to finish successfully but it doesn't look like pulp is fully working. I see that the workers aren't running:

$ sudo systemctl status -l pulp-worker@1                                                                    
‚óŹ pulp-worker@1.service - Pulp RQ Worker
   Loaded: loaded (/usr/lib/systemd/system/pulp-worker@.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Fri 2019-05-10 15:36:08 UTC; 21s ago
  Process: 20585 ExecStart=/usr/local/lib/pulp/bin/rq worker -w pulpcore.tasking.worker.PulpWorker -n reserved-resource-worker-%i@%%h --pid=
/var/run/pulp-worker-%i/reserved-resource-worker-%i.pid -c pulpcore.rqconfig (code=exited, status=200/CHDIR)
 Main PID: 20585 (code=exited, status=200/CHDIR)

May 10 15:36:08 pulp3-source-centos7.crake.example.com systemd[1]: Started Pulp RQ Worker.
May 10 15:36:08 pulp3-source-centos7.crake.example.com systemd[1]: Starting Pulp RQ Worker...
May 10 15:36:08 pulp3-source-centos7.crake.example.com systemd[1]: pulp-worker@1.service: main process exited, code=exited, status=200/CHDIR
May 10 15:36:08 pulp3-source-centos7.crake.example.com systemd[1]: Unit pulp-worker@1.service entered failed state.
May 10 15:36:08 pulp3-source-centos7.crake.example.com systemd[1]: pulp-worker@1.service failed.

Also, I noticed that workon pulp doesn't work either.

#13 Updated by rchan 5 months ago

  • Sprint changed from Sprint 52 to Sprint 53

#14 Updated by jsherril@redhat.com 5 months ago

I'm still seeing this with the centos7-pulp3-github box

#15 Updated by jsherril@redhat.com 5 months ago

a second katello dev has hit this as well.

#16 Updated by bmbouter 5 months ago

  • Priority changed from Normal to High

I think this is high prio

#17 Updated by amacdona@redhat.com 5 months ago

  • Sprint changed from Sprint 53 to Sprint 54

#18 Updated by daviddavis 5 months ago

  • Tags Katello-P2 added
  • Tags deleted (Pulp 3 installer)

#19 Updated by bmbouter 5 months ago

I think this an installer issue. Since Pulp is pure Python and all deps are too (except for pulp_rpm's deps) it's got to work since the Python 3.6 is also available for it.

#20 Updated by amacdona@redhat.com 5 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to amacdona@redhat.com

I was able to successfully use `vagrant up pulp3-source-centos7` with the file plugin. Whatever wasn't working before seems to be resolved.


http http://localhost:24817/pulp/api/v3/status/
HTTP/1.1 200 OK
Allow: GET, HEAD, OPTIONS
Connection: close
Content-Length: 1072
Content-Type: application/json
Date: Thu, 06 Jun 2019 15:18:11 GMT
Server: gunicorn/19.9.0
Vary: Accept
X-Frame-Options: SAMEORIGIN

{
    "database_connection": {
        "connected": true
    }, 
    "missing_workers": [], 
    "online_workers": [
        {
            "_created": "2019-06-06T15:03:55.480266Z", 
            "_href": "/pulp/api/v3/workers/c6a5a2b0-0980-4b7d-87c6-23d703e0ae41/", 
            "last_heartbeat": "2019-06-06T15:18:00.709374Z", 
            "missing": false, 
            "name": "reserved-resource-worker-1@pulp3-source-centos7.localhost.example.com", 
            "online": true
        }, 
        {
            "_created": "2019-06-06T15:03:56.064985Z", 
            "_href": "/pulp/api/v3/workers/02c4b629-7ecf-42dc-837c-cb17b2c5710b/", 
            "last_heartbeat": "2019-06-06T15:18:01.411367Z", 
            "missing": false, 
            "name": "reserved-resource-worker-2@pulp3-source-centos7.localhost.example.com", 
            "online": true
        }, 
        {
            "_created": "2019-06-06T15:03:57.748920Z", 
            "_href": "/pulp/api/v3/workers/583a9313-e679-4f44-94a2-ea6dc7894ff7/", 
            "last_heartbeat": "2019-06-06T15:18:02.212948Z", 
            "missing": false, 
            "name": "resource-manager@pulp3-source-centos7.localhost.example.com", 
            "online": true
        }
    ], 
    "redis_connection": {
        "connected": true
    }, 
    "versions": [
        {
            "component": "pulpcore", 
            "version": "3.0.0rc2" 
        }, 
        {
            "component": "pulpcore-plugin", 
            "version": "0.1.0rc2" 
        }, 
        {
            "component": "pulp_file", 
            "version": "0.1.0b1" 
        }
    ]
}

Just to be sure, I ran the upload and sync instructions from the pulp_file docs, which completed successfully. The only issue that I see is that the venv.bashrc is not created for centos (which allows `workon pulp`), but this can be worked around with `source <pulp_install_dir>/bin/activate`.

I'm taking this issue as assigned, and the only work for this will (hopefully) be enabling venv.bashrc. In the meantime, I think this work does not need to continue to block FIPS work.

#21 Updated by amacdona@redhat.com 5 months ago

  • Status changed from ASSIGNED to POST

#22 Updated by amacdona@redhat.com 5 months ago

  • Status changed from POST to MODIFIED

Please register to edit this issue

Also available in: Atom PDF