As it stands all packages/repos are stored in /var/lib/pulp and I'd like the ability to point these elsewhere (so that my massive packagesets can live on NFS). Right now I have moved /var/lib/pulp and symlinked it back but I feel this is the wrong approach and it would be better to just define the package storage location.
I understand that the below 2 bugs are slightly different but think it would be of great help in this context.
In short pulp.spec also needs to handle the permissions of the custom/separate disks partitions which stores repos/packages.
For this issue, we recommend mounting dedicated storage either at /var/, /var/lib/, or /var/lib/pulp/. Also note that mongo can quickly use many GB of storage, so consider making plenty of storage available at /var/lib/mongodb/.
Mounting an NFS device within /var/lib/ is quite reasonable. Also consider doing a bind mount, which lets you store the data on any part of your FS hierarchy you like.
/var/lib/ is the appropriate place to store application data. See the Filesystem Hierarchy Standard for details:
RHEL uses the FSH as its "authoritative reference": https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s1-filesystem-fhs.html
We will certainly consider ways to make it easier for sysadmins to deploy pulp with storage in non-standard locations.
Moved to https://pulp.plan.io/issues/162
*** Bug 1127809 has been marked as a duplicate of this bug. ***
Pulp will ensure that it works with /var/lib/pulp as a symlinked directory and document that this is a supported configuration of Pulp.
Hosting /var/lib/pulp (and other Pulp directories) on NFS is already a tested and supported configuration so that's also an option.
Either way, sat6 should use symlinks or NFS to store content in /var/lib/pulp on another area of the filesystem or other systems. Sat6 will need to configure this at install time. Feel free to needsinfo me with any questions.
The Pulp upstream bug priority is at Normal. Updating the external tracker on this bug.
*** This bug has been marked as a duplicate of bug 1159270 ***