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

[ENH] - Pinned environment versions for deployments #522

Open
mcg1969 opened this issue Nov 11, 2024 · 0 comments
Open

[ENH] - Pinned environment versions for deployments #522

mcg1969 opened this issue Nov 11, 2024 · 0 comments

Comments

@mcg1969
Copy link

mcg1969 commented Nov 11, 2024

Feature description

This is an enhancement that really crosses jhub-apps, conda-store, and nebari.

When deploying an application, the user selects an environment to deploy with. In nebari at least, the list of environments is managed by conda-store, and specifically selects the currently active version of each environment that is available.

But suppose someone modifies an environment in conda-store after an application is deployed. There is a nonzero chance that this will break an application that is already deployed, and/or change its behavior in unexpected ways. Specifically, when the deployment container is restarted for any reason, it will shift the environment from the old one to the new one. In the worst case, if conda-store ever prunes old environments from the NFS fileshare, a live running deployment will likely fail.

For this reason, some way to "pin" the deployed environment to the fixed version seen at deploy time seems important.

Certainly, if the deployer wants to change or update the environment being used by an application, they should be free to do so by editing the environment spec. But at least that's an explicit acknowledgement of risk.

Value and/or benefit

Better reproducibility for applications

Anything else?

No response

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

No branches or pull requests

1 participant