-
Notifications
You must be signed in to change notification settings - Fork 1
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
only provide the most recent kernel? #42
Comments
@pibion is there a way to access earlier kernels if they're not in the list? Part of the goal of CVMFS was to make sure that old releases are still around (a) for reproducibility and (b) so that your analysis won't break every time a new release comes out. Since this is early days, it probably wouldn't hurt to trim the older kernels from the list. But eventually all the kernels should stick around forever or very nearly so. Hopefully that will correspond to much slower release cycles, although I don't see that happening particularly soon |
as the functionality to add kernels is provided by the CDMS software stack, it would be better to implement there something like |
@bloer what do you think about adding a |
@bloer what do you think about adding my idea of adding a |
@zonca it turns out this would be useful for other deployment sites as well. The thing we're struggling with is that we'd like users to be able to access old versions for reproduciblity purposes. So then the question becomes: what versions do we really need to keep? |
@pibion as we have control of the
|
We're not deleting anything from cvmfs, so users can always reinstall an older kernel if needed. Can you remind me again how the kernel list is generated at XSEDE? At most of our sites, users have to install new kernels manually, but if I recall it's being done automatically at XSEDE, right? So the plan would be to also run the prune script automatically? Would a user wanting to stick with an older kernel have to manually reinstall it every session in that case? |
we have a it has to be executed manually (I tried to automate but failed, see #27), So maybe we should move |
I'm working on this, but hit an annoying snag. The "right" way to do this is with the |
@bloer what about having a minimal miniconda env just to handle this operation? |
@bloer would you have any update on this? |
@bloer I am reviewing the old issues, any suggestions about this? I was thinking about a minimal miniconda env just dedicated to handling |
I think it might be preferable to list only the most recent CDMS kernel - the list of available kernels is getting pretty long!
What do you think @bloer, @zonca?
The text was updated successfully, but these errors were encountered: