Migrate dnb03 mount point to dnb-ds03

[kysrpex]

I just searched the repo for dnb03 and this is what seemed relevant to me.

Related: usegalaxy-eu/mounts#11.

[kysrpex]

I am wondering... Were dnb01 and dnb02 also migrated in the past? Anybody knows why the mount points were not removed?

[sanjaysrikakulam]

Looks fine. Thank you!

[kysrpex]

To everybody, remember to wait until Thursday to merge this.

[sj213]

Hold it! This PR appears to generally substitute /data/dnb-ds03 for /data/dnb03 in all configuration options where the latter is contained. Furthermore, it removes the automount point /data/dnb03 from the autofs config entirely.

Are you positively sure that no files in the current /data/dnb03-tree outside of /data/dnb03/galaxy_db/files are needed any more? For Kolja's rsync-runs have AFAIK only copied the latter subtree, not the entire dnb03 directory tree. Once this PR is committed as-is, access to files located under /data/dnb03 but outside the Galaxy data store proper (i.e. anything not subject to DB indirection) will fail unless we copied this data ourselves.

[sj213]

Anybody knows why the mount points were not removed?

See my comment above for why - the cases of dnb{01,02,03} are all analogous. The original intent had been to migrate the legacy data stores to S3 storage rather than conventional NFS shares, but since that only works for files subject to DB indirection we had intended to keep the other files around under their old paths for the time being and consolidate them in an altogether new file tree to be created eventually. Galaxy's S3-backend wasn't ready in time, however, and the legacy data stores ended up on the "FabricPool" volumes of the Netapp - but we still kept the distinction, not least because we had wanted to make the initial switch by changing the Galaxy data store configuration, to wit, object_store_conf.xml, only and be able to defer migration of files outside of the DB-indirected data store. This, however, required keeping the old mount points around.

[kysrpex]

@sj213

Are you positively sure that no files in the current /data/dnb03-tree outside of /data/dnb03/galaxy_db/files are needed any more? For Kolja's rsync-runs have AFAIK only copied the latter subtree, not the entire dnb03 directory tree. Once this PR is committed as-is, access to files located under /data/dnb03 but outside the Galaxy data store proper (i.e. anything not subject to DB indirection) will fail unless we copied this data ourselves.

root@sn06:/data/dnb03$ tree -I "files|job_working_directory" -f /data/dnb03
/data/dnb03
├── /data/dnb03/check-dnb01
├── /data/dnb03/check-dnb02
├── /data/dnb03/check-dnb03
├── /data/dnb03/DATA.DNB03
├── /data/dnb03/foo2
│   ├── /data/dnb03/foo2/command.sh
│   ├── /data/dnb03/foo2/configs
│   │   └── /data/dnb03/foo2/configs/tool_script.sh
│   ├── /data/dnb03/foo2/external_id
│   ├── /data/dnb03/foo2/home
│   ├── /data/dnb03/foo2/inputs
│   │   ├── /data/dnb03/foo2/inputs/dataset_c3274971-bf04-4722-b3fd-118a6aae9cab.dat
│   │   └── /data/dnb03/foo2/inputs/dataset_d7d83138-925c-44f7-bf81-ddd17431995e.dat
│   ├── /data/dnb03/foo2/job_condor.log
│   ├── /data/dnb03/foo2/job.condor.submit
│   ├── /data/dnb03/foo2/launch_config
│   ├── /data/dnb03/foo2/metadata
│   │   ├── /data/dnb03/foo2/metadata/__instrument_core_epoch_start
│   │   ├── /data/dnb03/foo2/metadata/__instrument_core_galaxy_memory_mb
│   │   ├── /data/dnb03/foo2/metadata/__instrument_core_galaxy_slots
│   │   └── /data/dnb03/foo2/metadata/__instrument_hostname_hostname
│   ├── /data/dnb03/foo2/outputs
│   │   └── /data/dnb03/foo2/outputs/dataset_5d118fb5-4d91-4453-b94d-3b4aa9b58b47.dat
│   ├── /data/dnb03/foo2/preprocessed
│   ├── /data/dnb03/foo2/running
│   ├── /data/dnb03/foo2/stderr
│   ├── /data/dnb03/foo2/stdout
│   ├── /data/dnb03/foo2/tmp
│   ├── /data/dnb03/foo2/tool_files
│   ├── /data/dnb03/foo2/tool_id
│   ├── /data/dnb03/foo2/tool_script.sh
│   ├── /data/dnb03/foo2/tool_version
│   └── /data/dnb03/foo2/working
│       └── /data/dnb03/foo2/working/memory_statement.log
├── /data/dnb03/galaxy_db
│   ├── /data/dnb03/galaxy_db/test
│   │   └── /data/dnb03/galaxy_db/test/tmp
│   └── /data/dnb03/galaxy_db/tmp
└── /data/dnb03/test_rm_me

13 directories, 26 files
root@sn06:/data/dnb03$ ls /data/dnb03/galaxy_db/files/
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  _metadata_files
root@sn06:/data/dnb03$ ls /data/dnb03/galaxy_db/job_working_directory/
root@sn06:/data/dnb03$

root@sn06:~$ tree -I "files|job_working_directory" -f /data/dnb-ds03
/data/dnb-ds03
├── /data/dnb-ds03/galaxy_db
│   └── /data/dnb-ds03/galaxy_db/tmp
└── /data/dnb-ds03/migration-info-dnb03
    ├── /data/dnb-ds03/migration-info-dnb03/README.md
    └── /data/dnb-ds03/migration-info-dnb03/scandir_list_dnb03_db_files_2023-10-30.csv.zst

3 directories, 2 files
root@sn06:~$ ls /data/dnb-ds03/galaxy_db/files/
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  _metadata_files
root@sn06:~$ ls /data/dnb-ds03/galaxy_db/job_working_directory/
root@sn06:~$ 

(yes, I created some extra directories on dnb-ds03 for any path on the playbook referring to them, and adjusted their permissions to match)

Considering the outputs of tree, ls, and the above note, the rest of the stuff does not look critical to me. But it is good that you all have a look if you want. The intent is to get rid of stuff we do not need (i.e. the mountpoint) if we really do not need it.

[kysrpex]

This has been just been deployed, the log is here (Jenkins).