Meta issue for Conda-Store user experience

[iameskild]

Opening this issue to track all of the Conda-Store related user experience questions and issues. The goal is help users navigate the recent Conda-Store changes. Much of what is discussed below can be included in the docs eventually.

Questions:

• [ ] 1. When should new conda environments be created via the qhub-config.yaml and when should they be created from the /conda-store endpoint? And what difference does it make?
• [ ] 2. What are the steps to delete a conda environment I no longer need?
• [ ] 3. What are the differences between the default and filesystem namespaces?

Known issues:

• https://github.com/Quansight/qhub/issues/1158
• https://github.com/Quansight/qhub/issues/1021
  • related to how conda-store environments are used by CDS dashboards

[rsignell-usgs]

@iameskild , yes, @jkellndorfer and I are super confused about the new conda-store approach.

We originally added packages to our 0.4 Qhub deployment by going to the conda-store manager https://jupyter.data.science.earth/conda-store/, choosing a namespace, and dropping an environment.yml file in there.

Then we were told that if we want to have environments available for all users, we should add them in the config.yml the way we used to do and let github actions deploy them. So I've tried that, but when I look at the conda-store manager now I see my pangeo environment with 0 bytes, and a bunch of builds not working:

Questions:

• How to debug/recover from this?
• Can we still shell into the conda-store pod and delete environments?

[dharhas]

Getting back to one of my original points. 'default' and 'filesystem' are terrible names. Let's define what they are and use better names.

[costrouc]

@rsignell-usgs maybe we should schedule a call on this to talk about this. I agree that the naming is confusing and we haven't been clear on what is the best approach for managing the environment qhub-config.yaml vs conda-store. I'll message you on the OGC slack.

[viniciusdc]

@costrouc any updates on what has been decided?

[trallard]

@costrouc does this need to remain open? since everything is happening in conda-store (repo and the such) this seems stale now

[pavithraes]

Issue: In the new UI, we need to intermittently "login" to conda-store, and we need to click on the unintuitive profile icon to do so.

Solution: Ideally, we shouldn't need to login again if we're already logged-in to Nebari. At the very least, the "login" requirement should be more obvious and intuitive.

Dharhas said: One of the biggest overall issues with Nebari is the fact that we don't have a full single-sign on, each part requires going through the auth flow again (keycloak, argo, conda-store etc).

Originally discussed on Slack

[kcpevey]

This issue has been opened for a very long time and conda-store and the conda-store-ui have changed significantly. At this point, we request all UI/UX issues be opened here https://github.com/conda-incubator/conda-store-ui .

Before closing this issue, I'll comment on the original questions:

• When should new conda environments be created via the nebari-config.yaml and when should they be created from the /conda-store endpoint? And what difference does it make?
  • the recommendation is that all envs are built through the conda-store interface, though it is still possible that admins may want to define default envs in nebari-config.yaml.
• What are the steps to delete a conda environment I no longer need?
  • there is now a delete button in the ui
• Add a feature that auto-deletes everything but the past 5 builds per env.
  • We have an open issue to improve the build deletion process and options. I've added a note there