Closed dharhas closed 11 months ago
I think there may be two separate things here:
This env did build, the logs are available and it made it all the way to the final "to activate this env type conda activate..."
Its happening on the global/examples env on nebari.quansight.dev which is an existing env that is not being built.
We think we have the issue. It has to do with the UI not distinguishing between namespacea/env
and namespaceb/env
with how it stores state.
@kcpevey and I discussed this yesterday. I am adding a few notes that will help whoever tackles this.
🔍 This issue arises when the user has two environments with the same name in different namespaces. When a user tries and view any of those environments, conda-store fails to do so as it seems it is not making the differentiation of namespace-1
and namespace-2
and somehow only looking at environment names.
No error is thrown (not sure what the response is), and in any case, conda-store should always be namespace
and environment
aware.
Since I am unfamiliar with "how conda-store stores state" and why this would lead to the issue above (to me this from an API POV looks like we should be looking for unique URIs and validating at that point).
Since I am unfamiliar with "how conda-store stores state" and why this would lead to the issue above (to me this from an API POV looks like we should be looking for unique URIs and validating at that point).
I think this is entirely a frontend ui issue. Conda-store always needs namespace/environment-name when performing an action.
For detail on how conda store stores state there is a database diagram https://conda.store/en/latest/contributing.html#model. With a high and low level view.
Regardless of it being frontend only* - there is a miss on identifying the namespace to which each environment belongs, because this happens only when you have multiple envs with the same name. It is basically ignoring the principle that environments or builds exist always and only within a namespace.
How envs are retrieved and shown should follow that principle, the endpoints and data entries are there already. Ultimately both the backend and fronted should be aware of this organisational model and workflows should be designed with both composition (bringing different components together) and separation (where does the ownership/scope of a given component or workflow ends) in mind and that is not happening.
This issue is then not a projection (fetch and display or workflow representation through the interface) but a composition problem, the workflow to retrieve, handle, manage and present data is what is probably not well designed or robust enough. The state (data) and store are defined by the API and database model. That is what I was pointing at when I said I did not know why/how the data/state store would be the culprit when the workflow is what is not working as expected.
*I would not call this a frontend UI only issue if the problem is a composition or workflow one, this sounds more like a system/workflow design issue than a UI (user interface) one.
I have tried to reproduce this, but cannot. I have 3 envs with the same name in 3 different namespaces, and each of them show up as expected.
@kcpevey needs to reproduce
I've confirmed that I can't reproduce on 2023.9.2. Yay for free fixes! 🎉
Not sure how reproducible this is since I don't know what is causing it.Edit to include Chris' message:
In our JATIC Govcloud Nebari deployment, one of the environments does not load. It just shows spinning icons, in all sections except description:
If I switch to working environment i.e.
dashboard
and switch back to the
jatic-toolbox
environment, then the description from thedashboard
environment is shown.