Configuration repositories should be mounted first

[olemorud]

When cvmfs repositories are mounted through /etc/fstab entries, the configuration repository should be mounted first:
https://cvmfs.readthedocs.io/en/stable/cpt-configure.html#:~:text=If%20a%20configuration,mounts.%20For%20example%3A

Currently one has to manually patch each non-config repository like this

cvmfs::mount_method: mount
cvmfs::manage_autofs_service: false

cvmfs::cvmfs_hash:
  cvmfs-config.cern.ch:
    {}
  atlas.cern.ch:
    { options => 'defaults,_netdev,nodev,x-systemd.requires-mounts-for=/cvmfs/cvmfs-config.cern.ch', }
  atlas-nightlies.cern.ch:
    { options => 'defaults,_netdev,nodev,x-systemd.requires-mounts-for=/cvmfs/cvmfs-config.cern.ch', }
  # [...]

but it would be preferable to have the module do this automatically. Perhaps only requiring the user to specify which of the entries that is the config-repository.

[olemorud]

Also the config repository must appear first on the list, which is not possible to control when using the module (I suspect it adds them in alphabetical order instead)

[traylenator]

As long as we have - x-systemd.requires-mounts-for=/cvmfs/cvmfs-config.cern.ch' that should be enough?

Do we still need the order in fstab to be correct?

Part of problem here is when puppet calls mount itself these systemd orderings are all ignored so while fixing reboot is possible less obvious for when puppet runs... Can use puppet ordering I guess for that case.

[olemorud]

I was told by people in the cvmfs team (i.e. my only source is a private mattermost message) that the config repository also had to appear first in the list (I will test without anyways and report back).

[traylenator]

Its kind of irrelevant. if we put the puppet of cvmfs-config before say atlas the it will be first anyway in fstab.

Fixing existing installations for order in fstab is frankly to hard but they should be fine anyway on reboot since on reboot tis the systemd items that matter.

[traylenator]

Perhaps only requiring the user to specify which of the entries that is the config-repository.

Indeed this point is tricky.

cvmfs-config.cern.ch is indeed not the correct config repo for all repos out there.

Hard to know what to do other than:

class{'cvmfs':
  mount_method => 'mount',
 }
cvmfs::mount{'ams.cern.ch':
   config_repo = 'cvmfs-config.cern.ch',
}

could be made to work but a little long winded - I guess in reality when people explicitly
mount repos they only mount a few.

I'm also tempted to remove the ambiguity between the two way things get mounted.

1. When puppet runs for the first time with this configuration it calls /usr/bin/mount explicitly and only the
   contents of /etc/fstab are used, the x-requires is ignored in this case the ordering in the /etc/fstab is significant.

2. On reboot the /etc/fstab is pre-processed via systemd-fstab-generator.8.gz to create units which then then do the mounting respecting the ordering of the x-requries flag.

If I simply wrote the .mount units myself and stopped writing /etc/fstab then the same method would be used for both cases.

For transition a unit in /etc/ beets one in /run so the /etc/fstab entries would be ignored anyway in place of the ones just written.

🤔

[olemorud]

That could work.

cvmfs only allows one config repository per client ¹, which is not expected to change, so for the module interface it would probably be nice to have something like:

cvmfs::cvmfs_hash:
  cvmfs-config.cern.ch:
      { config_repo => true, }
  atlas.cern.ch:
      { }
  # [...]

Footnotes

1. https://cvmfs.readthedocs.io/en/stable/cpt-configure.html#:~:text=Also%20note%20that%20only%20one%20config%20repository%20may%20be%20used%20per%20client%2C%20and%20this%20is%20a%20technical%20limitation%20that%20is%20not%20expected%20to%20change. ↩

[traylenator]

One per client. That's a very useful bit of info.

Can be an attribute to the main class then.

Making it backwards compatible will be a small pain for people who have it mounted explicitly already but I'm sure nothing that cannot be solved.

Will put something together next week.

[traylenator]

Can be an attribute to the main class then

However given the mount has options maybe what you suggest better. Will work it out.