Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add repository metadata #81

Closed
bedroge opened this issue Apr 6, 2021 · 5 comments · Fixed by #161
Closed

Add repository metadata #81

bedroge opened this issue Apr 6, 2021 · 5 comments · Fixed by #161
Labels
configuration Improvements or additions to the configuration

Comments

@bedroge
Copy link
Collaborator

bedroge commented Apr 6, 2021

Related to #67, but it may also be useful to add some custom metadata, e.g. the latest version of the repo (requested by @ocaisa).

@bedroge bedroge added the configuration Improvements or additions to the configuration label Apr 6, 2021
@bedroge
Copy link
Collaborator Author

bedroge commented Apr 6, 2021

This should be added to our Stratum 0 playbook.

@bedroge
Copy link
Collaborator Author

bedroge commented Apr 6, 2021

The only tricky thing is that this playbook would need to run regularly in order to keep the latest entry up to date. Or, perhaps we could use a hook that will update this information whenever the symlink is changed:
https://cvmfs.readthedocs.io/en/stable/cpt-repo.html#customizable-actions-using-server-hooks

@rptaylor
Copy link

rptaylor commented May 11, 2021

Not sure if the repo metadata should be used to discover the latest repo version; they are updated by separate processes.

Try enabling CVMFS_VIRTUAL_DIR on your stratum 0 and take a look in the snapshots dir:
https://cvmfs.readthedocs.io/en/stable/apx-parameters.html

This also has the advantage that users can read any revision they want without having to change the client configuration and doing a config reload. Using variant symlinks involves changing the client config (but not sure if a config reload is required in that case.)

If you really do want to lock the repository on client to a fixed catalog revision for a long period of time, use CVMFS_ROOT_HASH or CVMFS_REPOSITORY_TAG (there might be another useful parameter for that too).
But changing client config and doing cvmfs_config reload frequently to update the client is not really practical, and has the disadvantage of coupling user activity with admin privileges required to reconfigure the client.

@rptaylor
Copy link

rptaylor commented May 11, 2021

Also keep in mind this is something you would probably want to synchronize across all nodes, and it is not possible to do an atomic update across all nodes in a cluster in a completely synchronized way, with psh or otherwise. There would always be some nodes that get changed sooner than others. So I think it would be better to handle this at the user application level, e.g. a script that selects one specific version of software to use, which will either work on all nodes or fail if the required version is not present on a node.

@rptaylor
Copy link

That being said I still recommend updating repo metainfo for other purposes, just not version discovery/management.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
configuration Improvements or additions to the configuration
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants