These are left over from the migration to the new NFS server(s) and right now it creates inconsistencies such as https://gerrit.wikimedia.org/r/#/c/344982/6/modules/labstore/files/nfs-manage-binds where we don't expect special share names to exist outside of the usual.
This should really be done in two parts:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • Bstorm | T126083 overhaul labstore setup [tracking] | |||
| Declined | None | T161834 Undo special tools-home and tools-project share definitions for NFS |
This should really be done in two parts:
- refactoring so that the paths used in tools for the share links are common to the rest of the projects
The share paths are the same for tools and the other projects, they are all served at /exp/project/<project>/<home|project>
unwinding the tools-home and tools-project to be 'home' and 'project'
Proposal:
By refactoring so that the paths used in tools for the share links are common to the rest of the projects I meant this :)
- Currently the mount paths for rest of projects and tools is different, all projects are mounted at /mnt/nfs/labstore-secondary-home and /mnt/nfs/labstore-secondary-project on the clients, and tools is at /mnt/nfs/labstore-secondary-tools-home and /mnt/nfs/labstore-secondary-tools-project. As a first step, we dual mount the tools share at the common mount path. (https://phabricator.wikimedia.org/P5241$98)
Seems reasonable here. A few things we have been bitten by in the past are: absents/presents not scoped to projects when we mean them to be and puppet declarative madness when changing from mounts that use the same paths (shouldn't be a problem anymore). For Symlink /data/project and /home to the new mount paths it gets chaotic on pooled exec nodes so I would vote if possible to do a depool/puppet/repool process. i.e. swapping out the underlying mountpath for running processes is hard to predict
- Symlink /data/project and /home to the new mount paths (https://phabricator.wikimedia.org/P5242$123)
- At this point /data/project and /home for tools is being served from the new mount path. We can absent the mounts at the old mount paths. First ensure => 'absent' the tools-home-on-labstore-secondary and tools-project-on-labstore-secondary mounts, run puppet; (https://phabricator.wikimedia.org/P5243$81) and next step clean up the code and run puppet (https://phabricator.wikimedia.org/P5243$251)
- Finally change tools-home and tools-project on nfs-mounts.yaml to home and project, and remove the special case if tools block from nfsclient.pp - This should be a no op, since the mounts are already being served and the symlinks exist. (https://phabricator.wikimedia.org/P5244)
At this point, I have expanded rather than reduced this tendency (unfortunately) to accommodate maps because they are on different servers while making the nfs-exportsd system a bit more general purpose.
When we dig back into the NFS issues, I want to see if we can address the complexity around mounts, but overall, a large shared NFS mount is not a good idea for Toolforge and must be replaced.
Since, modifying this would be a big mess right now, and we want to refresh these servers with a totally new design. We can make it look however we want when we copy the data in. I am not interested in putting the team or the users through the trouble of making it more consistent between now and then, though. It sounds unpleasant and, ultimately, not useful enough.