kubeapps
kubeapps copied to clipboard
vmware-tanzu
Unable to edit or delete newly created flux package repository
Scenario:
- user A has cluster admin access to namespace A
- user A logs in to portal, switch context to namespace A and creates a new flux repo there
- the repo is created successfully but EDIT, REFRESH and DELETE button are disabled. A bit ironic since REFRESH button was enabled in previous screen
Detailed repro steps: See attached .txt file, steps 1-22.
screen 1
screen 2
I guess this is an unintended side effect of #5480, @castelblanque ?
I would be surprised. My bits are from several days ago.
It might be two issues together. On one side, in the example the context is namespace a and the repo exists in namespace a, but it is being shown in the global part.
On the other side #5480 added a check for permissions, but precisely for Flux there is only the namespaced check done. No check for permissions in the global part, as there is no official global namespace for Flux.
Maybe we should change UI to show the repo in the namespaced section?
this division into global/namespaced doesn't really apply to flux very well. Its artificial. with flux you can use any repo from any namespace that you have access to. does that mean the repo is global or namespaced? I don't know
Agree, but it is true that any repo is strictly namespaced, as it lives in a specific namespace. The "global" label is indeed artificial. There could be a scenario where a user has a global Carvel repo and a Flux repo. In my opinion, in that case, UI should show the Carvel repo in the global section, and the Flux repo in the namespaced section (if context namespace is the one of the repo, of course).
yes, the repo "lives" in namespace X. But one may use the repo from namespace X to install a package in namespace Y, provided they have access to both X and Y. So is the repo global or namespaced? It sort of depends on "who's asking". If I am asking with the current context "X" maybe the answer is "namespaced"? If I'm asking with the current context "Y" maybe the answer is "global", just because one shouldn't be able to install packages from a namespaced repo in any namespace other than the one that repo lives in? Yikes Possibly I said what Rafa said in the last sentence
There is an upcoming redesign of the repositories UI that may ease this dichotomy, at least in that screen. #5515 I suggested to show all repos in a single table (not two different sections), and mark repos with a distinctive icon where considered "global" (i.e. packages can be installed into any ns).
+1 to this approach. It simplifies and improves the experience with a single list of repos and a field/column for the scope of each one.
In addition, we should differentiate three scopes for package repositories:
-
Namespaced -
Cluster -
Multi-cluster
IMO it is clearer than the current global, that it is valid for both cluster and multi-cluster scopes depending on the configuration. So we can have the following scenario:
| Cluster | Repository | Scope |
|---|---|---|
| Cluster A | Repo 1 | Namespaced |
| Cluster A | Repo 2 | Cluster |
| Cluster A | Repo 3 | Multi-cluster |
| Cluster B | Repo 3 | Multi-cluster |
| Cluster B | Repo 4 | Cluster |
Nowadays, Repo 2, Repo 3 and Repo 4 are all of them labeled as global.
Totally agree on the naming. cluster, cluster-wide,cluster-level..etc, sound more accurate instead of global.
Specially when it comes to multicluster, global gets confusing, e.g. "global to the cluster or global to multiple clusters?".
Is it ok if I create an issue to discuss the naming change?
I have also verified that on the bits from main today that kubeapps-operator (cluster-admin to every namespace) will have the same problem (EDIT and DELETE buttons are disabled)
I just tried this scenario on bits I built locally just now and it is still broken
The new method is called “GetPackageRepositoryPermissions“. I do not see it listed in your screenshot.
On my machine, I still see the old “can-I’ calls.
The new method is called “GetPackageRepositoryPermissions“. I do not see it listed in your screenshot. On my machine, I still see the old “can-I’ calls.
I am guessing you didn't look carefully? 2nd screenshot, it is highlighted
ah, yes, missed it. …
I guess the issue is that the UI is considering the flux repos to be “global” (they are listed in the global, as I think the backend flags them as “namespaced: false”). But then it looks in the “global” map built by the GetPermissions and sees everything as false because there is no cluster-wide rolebinding (as expected).
There is still one issue, which was not fixed in this issue/pr as it applies to all plugins: whenever the "show in all namespaces" switch is toggled on, then all actions for namespace repositories are disabled.
The reason is that the UI is fetching permissions for global scope only, and not for all namespaces involved. Such issue should be tackled as part of the repository UI revamp (issue #5515)