Pulp

Do you have any modifications that you would suggest for the pulp systemd service definitions to ensure that pulp starts after NFS?

Adding "After=remote-fs.target" to the unit secion seems to help.
I am by no means a systemd expert so there may be other/better solutions.

From my reading remote-fs.target is activated after the remote file systems are all mounted.
I made the change and celerybeat/resource_manager now start on boot where they did not before.

[Unit]
Description=Pulp's Celerybeat
After=network.target
After=remote-fs.target

A newer version of Pulp (iirc 2.7.0 beta+) will keep these pids on a local folder and not in the /var/lib/pulp. Even still, I think it would be good to have all Pulp services wait until the network is started. I think we should propogate the units change to all of our units files.

@rbarlow, what do you think?

@alvinstarr, do you have any interest in making a PR for that change?

I am new to this development process so at the risk of sounding stupid I
am happy to make a PR but what is a PR?

On 08/21/2015 03:53 PM, Pulp wrote:

On 08/21/2015 03:53 PM, Pulp wrote:

A newer version of Pulp (iirc 2.7.0 beta+) will keep these pids on a
local folder and not in the /var/lib/pulp. Even still, I think it would
be good to have all Pulp services wait until the network is started. I
think we should propogate the units change to all of our units files.

@rbarlow, what do you think?

For the network services I think this is a reasonable suggestion, though
I don't believe it will solve any issues that people might be
experiencing since our Celery code will keep attempting to connect to
its network dependencies until it is able. Thus, even without doing this
everything will work. I would say it's the "right thing", though I also
don't think it'll change anyone's experiences with Pulp in a noticeable way.

For the remote-fs, there's a way to add a symlink under /etc/systemd to
indicate that you want a service to start after another one. Since the
remote-fs is system-dependent (i.e., not everybody is hosting
/var/lib/pulp in NFS), I think this would be the way to go. I don't
recall the exact way to do this, but I believe you can learn about it here:

http://www.freedesktop.org/software/systemd/man/systemd.unit.html

--
Randy Barlow

On 08/23/2015 09:35 AM, Pulp wrote:

I am new to this development process so at the risk of sounding stupid I
am happy to make a PR but what is a PR?

A PR is a Pull Request on GitHub. Thanks for helping out!

--
Randy Barlow

+1 to doing it in a way that generalizes for more than just NFS.

We should make a change (or doc it) because the services will wait until the network becomes available, but if they can't start because the shared filesystem is down then they won't wait.

remote_fs.target is a bit of a blunt instrument.
It should not be true until all the remote filesystems(NFS,GFS,Gluster...) have been mounted.
I believe that remote_fs.target gets set to true when there are no(-more) remote filesystems to mount.
I have not tested this though.

On one hand pulp should not need to wait for /home/xxx to be mounted.
On the other hand pulp is the kind of application where it will burn up lots of space and be the kind of thing someone will want to mount on some form of remote storage.

There is a RequiresMountsFor feature in systemd and it looks like it may work and that would need to have a list of directories that would reasonably used.
So /var/lib/pulp/* should cover it.
That way pulp could start faster than having to wait for all the remote filesystems to mount.

RequiresMountsFor

Pulp 2 is approaching maintenance mode, and this Pulp 2 ticket is not being actively worked on. As such, it is being closed as WONTFIX. Pulp 2 is still accepting contributions though, so if you want to contribute a fix for this ticket, please reopen or comment on it. If you don't have permissions to reopen this ticket, or you want to discuss an issue, please reach out via the developer mailing list.