Project

Profile

Help

Issue #7255

pulp_installer via RPM does not account for pulp_install_dir

Added by ironfroggy 12 months ago. Updated 9 months ago.

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

Description

When installing via RPM there is no "pulp install directory" and the pulp_install_dir variable is either unnecessary or incorrect. This is currently blocking testing of the RPM installation.


Related issues

Related to Pulp - Story #7005: As a user, I can run a single stably-named Ansible role to install PulpCLOSED - CURRENTRELEASE

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>
Related to Pulp - Story #6793: [Epic] As a pulp_installer user, I can install Pulp from RPMsCLOSED - CURRENTRELEASE

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

Associated revisions

Revision 40950605 View on GitHub
Added by Mike DePaulo 12 months ago

Problem: pulp_installer via RPM does not account for pulp_install_dir

in systemd unit files, and any other task in the roles: pulp_api,pulp_content,pulp_workers,pulp_resource_manager, pulp_webserver

Solution: Delete all redundant default variables from these roles. Let them be inherited from pulp_common, now that the roles actually depend on pulp_common.

fixes: #7255 pulp_installer via RPM does not account for pulp_install_dir https://pulp.plan.io/issues/7255

Bug introduced during: related to: #6793 https://pulp.plan.io/issues/6793 As a pulp_installer user, I can install Pulp from RPMs

Redundant default variables are leftover from: related to: #7005 https://pulp.plan.io/issues/7005 As a user, I can run a single stably-named Ansible role to install Pulp

Revision 40950605 View on GitHub
Added by Mike DePaulo 12 months ago

Problem: pulp_installer via RPM does not account for pulp_install_dir

in systemd unit files, and any other task in the roles: pulp_api,pulp_content,pulp_workers,pulp_resource_manager, pulp_webserver

Solution: Delete all redundant default variables from these roles. Let them be inherited from pulp_common, now that the roles actually depend on pulp_common.

fixes: #7255 pulp_installer via RPM does not account for pulp_install_dir https://pulp.plan.io/issues/7255

Bug introduced during: related to: #6793 https://pulp.plan.io/issues/6793 As a pulp_installer user, I can install Pulp from RPMs

Redundant default variables are leftover from: related to: #7005 https://pulp.plan.io/issues/7005 As a user, I can run a single stably-named Ansible role to install Pulp

History

#1 Updated by ironfroggy 12 months ago

Can demonstrate the problem here, showing how the services attempt to be started and how they are incorrect. There is no virtualenv for pulp, package commands (like gunicorn) are in $PATH and don't need to be full paths.

[vagrant@localhost ~]$ cat /etc/systemd/system/multi-user.target.wants/pulpcore-api.service
[Unit]
Description=Pulp WSGI Server
After=network-online.target
Wants=network-online.target

[Service]
Environment="DJANGO_SETTINGS_MODULE=pulpcore.app.settings"
Environment="PULP_SETTINGS=/etc/pulp/settings.py"
Environment="PATH=/usr/local/lib/pulp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
User=pulp
Group=pulp
PIDFile=/run/pulpcore-api.pid
RuntimeDirectory=pulpcore-api
ExecStart=/usr/local/lib/pulp/bin/gunicorn pulpcore.app.wsgi:application \
          --bind '127.0.0.1:24817' \
          --workers 4 \
          --access-logfile -
ProtectSystem=full
PrivateTmp=yes
PrivateDevices=yes


# This provides reconnect support for PostgreSQL and Redis. Without reconnect support, if either
# is not available at startup or becomes disconnected, this process will die and not respawn.
Restart=always
RestartSec=3

# This directive is set to an absolute path in other Pulp units. Using an
# absolute path is an abuse of the directive, as it should be a relative path,
# not an absolute path. PIDFile is now used to ensure that PID files are laid
# out in a standard way. If this directive had any other effects, it is better
# to use the correct directive than to uncomment this.
# WorkingDirectory=/var/run/pulpcore-api/

[Install]
WantedBy=multi-user.target
[vagrant@localhost ~]$ /usr/local/lib/pulp/bin/gunicorn pulpcore.app.wsgi:application --bind '127.0.0.1:24817' \
>           --workers 4 \
>           --access-logfile -
-bash: /usr/local/lib/pulp/bin/gunicorn: No such file or directory

#2 Updated by mdepaulo@redhat.com 12 months ago

  • Assignee set to mdepaulo@redhat.com

The issue has something to do with: https://github.com/pulp/pulp_installer/blob/3.5.0/roles/pulp_common/defaults/main.yml#L18

pulp_install_dir: '{{ (pulp_install_source == "packages") | ternary("/usr", "/usr/local/lib/pulp") }}'

I added debug tasks and determined that pulp_common sees pulp_install_dir as /usr/ , but pulp_api sees it as /usr/local/lib/pulp . I'm investigating & implementing a fix now.

#3 Updated by mdepaulo@redhat.com 12 months ago

The isssue was caused by roles like pulp_api having lines in their defaults/main.yml like: pulp_install_dir: "/usr/local/lib/pulp"

I fixed it by removing all of those defaults, incorrect or correct, that are now duplicate. They became duplicate because this change made those roles actually depend on pulp_common.

https://pulp.plan.io/issues/7005

As a user, I can run a single stably-named Ansible role to install Pulp

#4 Updated by mdepaulo@redhat.com 12 months ago

  • Related to Story #7005: As a user, I can run a single stably-named Ansible role to install Pulp added

#5 Updated by mdepaulo@redhat.com 12 months ago

  • Related to Story #6793: [Epic] As a pulp_installer user, I can install Pulp from RPMs added

#6 Updated by pulpbot 12 months ago

  • Status changed from NEW to POST

#7 Updated by Anonymous 12 months ago

  • Status changed from POST to MODIFIED

#8 Updated by ttereshc 9 months ago

  • Sprint/Milestone set to 3.8.0

#9 Updated by ttereshc 9 months ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF