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.
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