search

helm / chartmuseum

helm chart repository server
https://chartmuseum.com
Apache License 2.0
3.58k stars 400 forks source link

API for listing organizations/repoes in multitenant mode #219

Open fmotrifork opened 5 years ago

fmotrifork commented 5 years ago

I would like to implement a version of ChartMuseumUI that allows the user to browse trough organizations and repoes to list the charts. For this I need an API endpoint that lists which organizatinos are created in ChartMusen.

An option would be to register an endpoint on 'http://localhost:8080/api/' that returns a list of orgs and repos (dependent on the depth set in the chartmuseum config)

GET http://localhost:8080/api/
org1/repoa/charts
org1/repob/charts
org2/repo1/charts

As JSON of cause.. ;)

jdolitsky commented 5 years ago

@fmotrifork Hi thanks for opening. Thanks for your work on ChartMuseumUI

Do you have a suggestion for how to implement this? The problem we have is that this information is not backed by any sort of relational database, so any combo of \<org>/\<repo> is treated as valid, its only a matter of access and # of charts located in a given location

fmotrifork commented 5 years ago

Hmm.. I guess the right way would be to add an extra function to the Backend interface at 'chartmuseum/storage' that allows listing all "prefixes"?

A quick hack could be to 'ListObjects' with an empty prefix. And use that to build a list of all existing org/repos...

jdolitsky commented 5 years ago

That sounds reasonable. And "listing all prefixes" would mean what exactly? Storage paths at depth X that are non-empty?

fmotrifork commented 5 years ago

Yes. That was my idea.

But I don't know if all the current storage backends are capable of listing "non-empty" paths, or just listing all paths that exist... And I am a bit afraid that listing all objects in a storage backend just to figure out which paths are non-empty could be very expensive.

We may have to consider slacking a bit on that requirement, and instead inform people that of they don't want to see an organization in the API that has no chats, then they need to delete the folder?

jdolitsky commented 5 years ago

It would seem to me that ChartMuseum UI at some point would want to incorporate some sort of users/RBAC system on top of it. Maybe now is a good time to introduce a database (postgres?) in that project and start doing interesting things like

ChartMuseum can continue to be used as the app's storage backend, and the token auth library can be used to authorize requests from service to service: https://github.com/chartmuseum/auth

What do you think?

fmotrifork commented 5 years ago

I had hoped we could keep CM UI stateless. That makes it much easier for new users to start using it.

An other problem with creating and keeping the organizations in a db in UI is that users can still create new organizations by POST'ing to ChartMuseum directly. This means we still need to scan CM every time (or at least very often) to actually show which organizations exists.

Using the auth lib would be awesome, as it also gives the users an easy way to acquire a token to CM without everyone knowing the master secret.. I was playing with the idea of using an SSO provider instead of implementing a full user database.