helm / chartmuseum

helm chart repository server

Helm

Helm is a tool for managing Charts. Charts are packages of pre-configured Kubernetes resources.

Use Helm to:

• Find and use popular software packaged as Helm Charts to run in Kubernetes
• Share your own applications as Helm Charts
• Create reproducible builds of your Kubernetes applications
• Intelligently manage your Kubernetes manifest files
• Manage releases of Helm packages

Helm in a Handbasket

Helm is a tool that streamlines installing and managing Kubernetes applications. Think of it like apt/yum/homebrew for Kubernetes.

• Helm renders your templates and communicates with the Kubernetes API
• Helm runs on your laptop, CI/CD, or wherever you want it to run.
• Charts are Helm packages that contain at least two things:
  • A description of the package (Chart.yaml)
  • One or more templates, which contain Kubernetes manifest files
• Charts can be stored on disk, or fetched from remote chart repositories (like Debian or RedHat packages)

Install

Binary downloads of the Helm client can be found on the Releases page.

Unpack the helm binary and add it to your PATH and you are good to go!

If you want to use a package manager:

• Homebrew users can use brew install helm.
• Chocolatey users can use choco install kubernetes-helm.
• Scoop users can use scoop install helm.
• Snapcraft users can use snap install helm --classic

To rapidly get Helm up and running, start with the Quick Start Guide.

See the installation guide for more options, including installing pre-releases.

Docs

Get started with the Quick Start guide or plunge into the complete documentation

Roadmap

The Helm roadmap uses GitHub milestones to track the progress of the project.

Community, discussion, contribution, and support

You can reach the Helm community and developers via the following channels:

• Kubernetes Slack:
  • #helm-users
  • #helm-dev
  • #charts
• Mailing List:
  • Helm Mailing List
• Developer Call: Thursdays at 9:30-10:00 Pacific (meeting details)

Contribution

If you're interested in contributing, please refer to the Contributing Guide before submitting a pull request.

Code of conduct

Participation in the Helm community is governed by the Code of Conduct.

chartmuseum's Issues

Bug: Deleting a chart having a suffix in its version via the API causes no removal from index

Hello,

We observed that deleting a chart having a suffix in its version via the API causes no removal from the index. The deletion from the file system works:

POST, GET, DELETE for chart having a version without suffix:

curl -X POST -k --data-binary "@mychart-1.0.4.tgz" localhost:8080/api/charts
{"saved":true}

curl localhost:8080/api/charts
{"mychart":[{"name":"mychart","version":"1.0.4","description":"mychart","apiVersion":"v1","urls":["charts/mychart-1.0.4.tgz"],"created":"2017-11-24T16:09:28.993494102+01:00","digest":"a4f08b5a9ccd5a958429c3ecf5fa45fdf2f271882cba7924c4fc9204645a8c7f"}]}

curl -X DELETE  localhost:8080/api/charts/mychart/1.0.4
{"deleted":true}

curl localhost:8080/api/charts
{}

POST, GET, DELETE for chart having a version with suffix:

curl -X POST -k --data-binary "@mychart-1.0.4-SNAPSHOT.tgz" localhost:8080/api/charts
{"saved":true}

curl localhost:8080/api/charts
{"mychart":[{"name":"mychart","version":"1.0.4-SNAPSHOT","description":"mychart","apiVersion":"v1","urls":["charts/mychart-1.0.4-SNAPSHOT.tgz"],"created":"2017-11-24T16:09:28.993494102+01:00","digest":"a4f08b5a9ccd5a958429c3ecf5fa45fdf2f271882cba7924c4fc9204645a8c7f"}]}

curl -X DELETE  localhost:8080/api/charts/mychart/1.0.4-SNAPSHOT
{"deleted":true}

curl localhost:8080/api/charts
{"mychart":[{"name":"mychart","version":"1.0.4-SNAPSHOT","description":"mychart","apiVersion":"v1","urls":["charts/mychart-1.0.4-SNAPSHOT.tgz"],"created":"2017-11-24T16:09:28.993494102+01:00","digest":"a4f08b5a9ccd5a958429c3ecf5fa45fdf2f271882cba7924c4fc9204645a8c7f"}]}

Best regards,
Andreas

Race condition observed with high chart count

Hi,

We have stumbled upon a problem with our CM instance where suddenly only about half of our Google Storage backed charts were being served (without any error or hint in the debug logs whatsoever). Upon inspection, we have found this to be due to a race condition in server.addIndexObjectsAsync, where the function-global err variable can be set to non-nil by a first goroutine, while being reset just after by another, effectively fighting to set the error condition. The effect of this is that storage download errors can easily be hidden away by the concurrency logic. The more charts there are, the more likely this is to happen also. It's easy to simulate this problem by adding this block:

if rand.Float64() < 0.9 {
    return new(helm_repo.ChartVersion), fmt.Errorf("simulated IO error")
}

in server.getObjectChartVersion.

With this simulated error code added, the initial index creation code should very likely fail (rerun until it does if you get "lucky"), while it doesn't, which is wrong.

We have a fix on the burner for this coming soon.

TLS Client Cert Authentication

This is related to the excellent proposal in #59, but should be solvable immediately rather than as a long-term effort.

The Helm client supports TLS client certificate authentication:
helm/helm#1038 (comment)

It would be great if chartmuseum supported a --tls-ca-cert which would perform client certificate authentication of incoming requests, accepting client certs issued by the trusted CA.

Perhaps this is already supported, but I can't find it in the documentation.

Use dep as package manager

The go community is moving to dep as the official packaging solution.

glide is in maintenance mode only.

Chartmuseum apparently not closing files when scanning repo

It looks as if chartmuseum may not be closing files when it scans the repo. We are looking at converting a large repo (nearly 16000 packages) to chartmuseum and are getting the following error on the initial scan:
open helmrepo/xxx.tgz: too many open files in system

I haven't dug through the code yet, but my assumption is that when it first scans the repo it open each file and doesn't close it before opening the next, or it parallelizes the scan and opens so many files that it hits the file descriptor limit. For now, I have bumped by ulimit to get around this error, but I may not be able to do that in production.

Auto-generate index.yaml

It would be nice if, after uploading a new or updated chart, the index.yaml-file is automatically generated for the repository, so users don't have to generate and upload it manually.

More robust authentication

Currently the Helm repo standard is to use anonymous HTTP or HTTP Basic authentication. This is a proposal to support a more robust authentication scheme with Chart Museum. Hopefully it will be embraced by Helm. If it won't, it still shouldn't affect Chart Museum's compliance with the Helm repo standard since this is an additional functionality on top of the standard functionality.

This was originated from the discussion around Multi-tenancy to Chart Museum, but it's a good feature for single-tenant users also hence this issue to kick-off this discussion as well.

OAuth/JWT clarification:
OAuth2 is the common protocol for API authorization. It defines a set of scenarios (flows) that each describe how the client, server (resource server) and authorization server can work together to allow a client application to obtain an access token to some protected resources. The result of this auth dance is a token which the client can use for accessing the resources. The most common type of token is JWT, which is basically a signed JSON document with an agreed upon schema. When a user gets hold of a valid JWT (by following OAuth2, or by any other means), they will present it to the server which will validate the token, after which point the request is authenticated, and may proceed to making authorization decisions which are out of scope for now.

Chart Museum is a server that hosts charts. In OAuth2 lingo it is a resource server which rely on some other party to issue tokens. If we look at Docker Registry for reference, it seem to take similar approach of promoting OAuth2, but the open registry implementation (distribution) does not implement the entire flow (at least not as part of core), it expects the token to be issued by another component.

Taking this approach has the following benefits:

• Doesn't require a database (as requested by early adopters) but make it optional
• Cleanly integrate into hosting environments
• Leverage existing OAuth/JWT frameworks

To implement this, Chart Museum needs to accept JWT token:

• bootstrap CM using certain configuration like: trusted authorization server URL, valid signing keys, etc
• add a middleware that will enforce auth
• extract the token from the Authorization header
• validate the token
• examine allowed actions for this token (scopes)
• allow/disallow the request (disallow should return 401 with information on the required authentication)

References:

• OAUTH2 vs JWT: https://community.apigee.com/questions/21139/jwt-vs-oauth.html
• Docker Hub OAuth2: https://docs.docker.com/registry/spec/auth/token/
• Simple JWT validation as Gin middleware: https://github.com/gin-gonic/contrib/tree/master/jwt
• JWT verifivation details: https://auth0.com/docs/api-auth/tutorials/verify-access-token
• Docker registry (distribution) reference implementation of authorization server: https://github.com/docker/distribution/tree/master/contrib/token-server
• Docker Registry oss authorization server: https://github.com/cesanta/docker_auth
• Sample setup of Docker Registry, Docker Authorization Server, and Identity Provider: https://github.com/kwk/docker-registry-setup

Missing an "http auth free" health endpoint

Hi,

It would be nice to have a health endpoint at path / which is exposed without http auth even if we use http auth.

For now I can't use my chartmuseum Helm charts with http auth in my Kubernetes cluster with a GCE Ingress because healthcheck fail indefinitely. :/

2017-12-12T16:16:26.486Z        DEBUG   [322] Incoming request: /       {"reqID": "ead60a6a-defe-4450-aa35-0db06b7ba857"}
2017-12-12T16:16:26.486Z        WARN    [322] Request served    {"path": "/", "comment": "", "latency": "127.6µs", "clientIP": "10.240.0.12", "method": "GET", "statusCode": 404, "reqID": "ead60a6a-defe-4450-aa35-0db06b7ba857"}
2017-12-12T16:16:26.616Z        DEBUG   [323] Incoming request: /       {"reqID": "780a8a2e-4faf-4deb-840e-d311db2e5dc6"}
2017-12-12T16:16:26.616Z        WARN    [323] Request served    {"path": "/", "comment": "", "latency": "33.093µs", "clientIP": "10.240.0.17", "method": "GET", "statusCode": 404, "reqID": "780a8a2e-4faf-4deb-840e-d311db2e5dc6"}
2017-12-12T16:16:26.746Z        DEBUG   [324] Incoming request: /       {"reqID": "6fe8e465-30ec-41cd-8687-9b59d39b6e73"}
2017-12-12T16:16:26.746Z        WARN    [324] Request served    {"path": "/", "comment": "", "latency": "37.049µs", "clientIP": "10.240.0.4", "method": "GET", "statusCode": 404, "reqID": "6fe8e465-30ec-41cd-8687-9b59d39b6e73"}

Chart already exists should not be a 500

500 indicates something went wrong at the server side.

I suggest chartmuseum should return a 403 Forbidden (as it's not overwriting) or vaguely possibly 400 Bad Request (as you should not try to overwrite a chart).

Single-tenant server should be moved to its own subpackage

Functionality in cache.go, routes.go, and handlers.go should be moved into a new subpackage so that additions of multi-tenancy features will not affect the current system.

Probably done by making Server an interface with a .Listen() method that is implemented in both the singletenant and multitenant subpackages.

cc @liamawhite

bucket is not in region error

I can't start my chartmuseum app because of the BucketRegionError: incorrect region, the bucket is not in 'us-west-2' region error

⇒  docker run --rm -it \
  -p 8080:8080 \
  -v ~/.aws:/root/.aws \
  chartmuseum/chartmuseum:v0.1.0 \
  --debug --port=8080 \
  --storage="amazon" \
  --storage-amazon-bucket="s***" \
  --storage-amazon-prefix="" \
  --storage-amazon-region="us-west-2"
2017-11-15T00:47:30.223Z        DEBUG   chartmuseum/server.go:166       Acquiring storage cache lock
2017-11-15T00:47:30.255Z        DEBUG   chartmuseum/server.go:168       Storage cache lock acquired
2017-11-15T00:47:30.841Z        DEBUG   chartmuseum/server.go:170       Releasing storage cache lock
BucketRegionError: incorrect region, the bucket is not in 'us-west-2' region
        status code: 301, request id: , host id:

If I would have done the same thing with aws s3 ls in the same container it works

⇒  docker run --rm \
>   -v ~/.aws:/root/.aws:ro \
>   --entrypoint sh \
>   chartmuseum/chartmuseum:latest \
>   -c 'apk add --update py-pip &&
quote>       pip install awscli &&
quote>       aws s3 ls s*** --region=us-west-2'
fetch http://dl-cdn.alpinelinux.org/alpine/v3.6/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.6/community/x86_64/APKINDEX.tar.gz
(1/12) Installing libbz2 (1.0.6-r5)
(2/12) Installing expat (2.2.0-r1)
(3/12) Installing libffi (3.2.1-r3)
(4/12) Installing gdbm (1.12-r0)
(5/12) Installing ncurses-terminfo-base (6.0_p20170930-r0)
(6/12) Installing ncurses-terminfo (6.0_p20170930-r0)
(7/12) Installing ncurses-libs (6.0_p20170930-r0)
(8/12) Installing readline (6.3.008-r5)
(9/12) Installing sqlite-libs (3.20.1-r0)
(10/12) Installing python2 (2.7.13-r1)
(11/12) Installing py-setuptools (33.1.1-r1)
(12/12) Installing py2-pip (9.0.1-r1)
Executing busybox-1.26.2-r7.trigger
OK: 62 MiB in 24 packages
Collecting awscli
  Downloading awscli-1.11.185-py2.py3-none-any.whl (1.2MB)
Collecting botocore==1.7.43 (from awscli)
  Downloading botocore-1.7.43-py2.py3-none-any.whl (3.7MB)
Collecting docutils>=0.10 (from awscli)
  Downloading docutils-0.14-py2-none-any.whl (543kB)
Collecting colorama<=0.3.7,>=0.2.5 (from awscli)
  Downloading colorama-0.3.7-py2.py3-none-any.whl
Collecting PyYAML<=3.12,>=3.10 (from awscli)
  Downloading PyYAML-3.12.tar.gz (253kB)
Collecting rsa<=3.5.0,>=3.1.2 (from awscli)
  Downloading rsa-3.4.2-py2.py3-none-any.whl (46kB)
Collecting s3transfer<0.2.0,>=0.1.9 (from awscli)
  Downloading s3transfer-0.1.11-py2.py3-none-any.whl (54kB)
Collecting python-dateutil<3.0.0,>=2.1 (from botocore==1.7.43->awscli)
  Downloading python_dateutil-2.6.1-py2.py3-none-any.whl (194kB)
Collecting jmespath<1.0.0,>=0.7.1 (from botocore==1.7.43->awscli)
  Downloading jmespath-0.9.3-py2.py3-none-any.whl
Collecting pyasn1>=0.1.3 (from rsa<=3.5.0,>=3.1.2->awscli)
  Downloading pyasn1-0.3.7-py2.py3-none-any.whl (63kB)
Collecting futures<4.0.0,>=2.2.0; python_version == "2.6" or python_version == "2.7" (from s3transfer<0.2.0,>=0.1.9->awscli)
  Downloading futures-3.1.1-py2-none-any.whl
Collecting six>=1.5 (from python-dateutil<3.0.0,>=2.1->botocore==1.7.43->awscli)
  Downloading six-1.11.0-py2.py3-none-any.whl
Installing collected packages: six, python-dateutil, jmespath, docutils, botocore, colorama, PyYAML, pyasn1, rsa, futures, s3transfer, awscli
  Running setup.py install for PyYAML: started
    Running setup.py install for PyYAML: finished with status 'done'
Successfully installed PyYAML-3.12 awscli-1.11.185 botocore-1.7.43 colorama-0.3.7 docutils-0.14 futures-3.1.1 jmespath-0.9.3 pyasn1-0.3.7 python-dateutil-2.6.1 rsa-3.4.2 s3transfer-0.1.11 six-1.11.0
                           PRE AWSLogs/

Any idea what causes this ?

Rename port "chartmuseum" to "http" for Istio compatibility

Ay,

Is it possible to rename port "chartmuseum" to "http" (or even "http-chartmuseum") in chartmuseum service to allow compatibility with istio ingress ?

Regards,

Option to use Redis in place of in-memory cache

In support of multitenancy, structs that used to generate index.yaml should be able to be stored in Redis to tackle scale

Azure backend reloads chart packages despite no changes

In an Azure blob storage container with a single, unmodified chart (chartmuseum-0.3.3.tgz), index.yaml is regenerated every time it is requested, despite no changes in storage.

Example output:

{"L":"DEBUG","T":"2018-02-19T11:27:25.561-0600","M":"Fetching chart list from storage"}
{"L":"DEBUG","T":"2018-02-19T11:27:25.852-0600","M":"Regenerating index.yaml"}
{"L":"DEBUG","T":"2018-02-19T11:27:25.852-0600","M":"Loading charts packages from storage (this could take awhile)","total":1}
{"L":"DEBUG","T":"2018-02-19T11:27:26.006-0600","M":"Adding chart to index","name":"chartmuseum","version":"0.3.3"}
{"L":"DEBUG","T":"2018-02-19T11:27:26.007-0600","M":"index.yaml regenerated"}
{"L":"INFO","T":"2018-02-19T11:27:26.007-0600","M":"Starting ChartMuseum","port":8080}
{"L":"DEBUG","T":"2018-02-19T11:27:28.977-0600","M":"[1] Incoming request: /index.yaml","reqID":"c6c84c97-2335-4619-9a48-049126602c7e"}
{"L":"DEBUG","T":"2018-02-19T11:27:28.977-0600","M":"[1] Fetching chart list from storage","reqID":"c6c84c97-2335-4619-9a48-049126602c7e"}
{"L":"DEBUG","T":"2018-02-19T11:27:29.068-0600","M":"[1] Regenerating index.yaml","reqID":"c6c84c97-2335-4619-9a48-049126602c7e"}
{"L":"DEBUG","T":"2018-02-19T11:27:29.188-0600","M":"[1] Updating chart in index","name":"chartmuseum","version":"0.3.3","reqID":"c6c84c97-2335-4619-9a48-049126602c7e"}
{"L":"DEBUG","T":"2018-02-19T11:27:29.188-0600","M":"[1] index.yaml regenerated","reqID":"c6c84c97-2335-4619-9a48-049126602c7e"}
{"L":"INFO","T":"2018-02-19T11:27:29.188-0600","M":"[1] Request served","path":"/index.yaml","comment":"","latency":"211.369ms","clientIP":"::1","method":"GET","statusCode":200,"reqID":"c6c84c97-2335-4619-9a48-049126602c7e"}

New multi-tenancy features should be opt-in

A flag should be added to the CLI that explicitly enables experimental new features and routing discussed in #53.

Unless this flag is specified, ChartMuseum will function as usual.

Provide a flag that allows anonymous read on GET operations when basic auth is used

It would be handy if there was a flag we could use to allow folks to GET charts anonymously when basic auth is used. This means that basic auth would only be required to PUT, PATCH and DELETE charts.

I have a PR on its way that does this but I figured it's best to raise an issue to discuss it and track any other proposed solutions.

How to add chartmuseum as an App Repository in Kubeapps

Hi,
I am very amazed with the chartmuseum. May I know if there is a way to add chartmuseum as an App Repository in Kubeapps. This can help me manage and deploy my helm releases in a very nice way.

Not supporting AWS profile and role

Hello,

Thanks for your work !

I'm trying to connect Chartmuseum to my AWS S3 bucket with a specific AWS role but I get a non authorized error.

I used this following command:

chartmuseum --debug --port=8080   --storage="amazon"   --storage-amazon-bucket=sandbox-helm-repository   --storage-amazon-prefix="" --storage-amazon-region="eu-west-1"

And I obtain this error:

AccessDenied: Access Denied
        status code: 403, request id: 2CE16226AA976744, host id: d/nSvAGPoReekLS2uEmhLpLA9kN7IWSiXrMVN+ZjRgcLrZZGqFvf6g+iUuU6xoje2si7m3nlfrA=

My file ~/.aws/credentials looks like this:

[default]    
aws_secret_access_key = my_secret_acces_key
aws_access_key_id = my_access_key_id 
[sandbox]
role_arn = arn:aws:iam::997909197264:role/OrganizationAccountAccessRole
source_profile = default

And my file ~/.aws/config looks like this:

[default]
region = eu-west-1

The command aws s3 ls --profile=sandbox works and give me the bucket with the profile Sandbox.

Do you know how I can use profile and aws role with Chartmuseum ?

Thank you !

Add possibility to overwrite chart in repository

Hi there,

it should be possible to overwrite existing charts served by the museum (i.e. to use PUT for creation and POST for updating a chart resource) - this would be especially useful when serving charts still under development. (similar to the possibility of uploading maven snapshots several times in the Java world)

This feature should be disabled by default and optionally enabled by providing a cmdline option, env var or something similar.

Best regards,
Andreas

Multitenancy

One ChartMuseum instance should be able to optionally provide multiple Helm repos

Add gin authentication middleware with support for basic auth and oauth2

To enable #59. Basic auth code should move here too.

Configurable modes:

• Off
• Basic Auth
• Basic Auth (GET protected)
• OAuth2

s3 storage: add support for server side encryption

It would be nice if chartmuseum could support sse with s3.

Chartmuseum cannot hold a constant response time when latency to storage is high

This was discussed in the #chartmuseum slack channel.

On Google Cloud Storage, we are running chartmuseum with around 60 charts and their versions. This makes about 800 versioned charts. The index update is causing latency problems in presence of new uploads. The server cannot keep up, and response times keep getting higher and higher, caused by a threading "bubble effect". This happens when the latency to storage is very high. It can also happen if the index is big.

Here is what happens currently:

Someone posts a new chart to storage.

1. /index.yaml detects the change
2. chartmuseum wants to recalculate the diff
3. another /index.yaml comes in (while 1) is not fninished),
   goto 2)

You see the picture. Every other index (while the first one is being calculated) is in wait state to redo the update, causing accumulated waits.

This issue is to track an upcoming PR which fixes the problem.

Add restricted IAM Policy for S3 Storage in documentation

We already talked about this in #2.
The goal is to get a restricted IAM Policy for S3 Storage.

Add Prometheus metrics

Hi Josh,

I have another request which stems from a requirement in the business context where we'll use ChartMuseum (but would also make sense in a more general context I believe): add Prometheus metrics, using https://github.com/prometheus/client_golang.

Things it would be nice to (optionally) measure:

• Number of requests, by type
• Duration of requests
• Number of charts served
• Time it takes to regenerate index
• Etc.

What do you think? Of course if you agree once more, I'll be happy to propose an implementation.

Change behaviour for root API route.

Currently,/ returns a 404. We are interested in changing this behaviour to return a redirect to /index.yaml.

During a discussion on slack with @jdolitsky. He suggested that maybe this route could return the version of chart museum that is running, but thinking through this later I thought that this is a potential security risk. Generally, you should not tell users the version of an application you are running because then they can cross reference that against potential exploits.

I am happy to do the legwork but the exact solution should probably be a result of some discussion.

Question for --allow-overwrite

Hi,

I'm not sure my question is regarding chart repo or chartmuseum, is it allow to store multiple versions of a chart? For example, I have a chart named nginx, I uploaded version 1.0.0 and 1.0.1, should I see both versions by helm search? Actually, I used --allow-overwrite parameter for chartmuseum, I can see chart 1.0.0.tgz and 1.0.1.tgz were both in the chart storage, but can only see version 1.0.1 by helm search, means only 1.0.1 in index.yaml, is this the expected behavior?

customizable S3 endpoint

Hi,

i'd like to use chartmuseum with my own S3 Storage Backend like mini.io.

Would it be possible to make S3 endpoint customizable?

with ruby lib fog-aws this possible: https://github.com/minio/cookbook/blob/master/docs/fog-aws-for-ruby-with-minio.md#3-example

Could it possible that, the aws lib you use already supports custom endpoints? https://github.com/aws/aws-sdk-go/blob/master/example/aws/endpoints/customEndpoint/customEndpoint.go

greetings
Andre

Separate API packages

The 3 categories under API in the readme

• Helm Chart Repository
• Chart Manipulation
• Server Info

should each have their own subpackage/file

Enable CRUD API (Chart Manipulation routes) in multitenant server

We could likely get away with using the same routes:

• POST /api/charts - upload a new chart version
• POST /api/prov - upload a new provenance file
• DELETE /api/charts/<name>/<version> - delete a chart version
• GET /api/charts - list all charts
• GET /api/charts/<name> - list all versions of a chart
• GET /api/charts/<name>/<version> - describe a chart version

We just need a way to pass in the name of the repo. Should we do so in the headers?

ChartMuseum-Repo: org1/repo1

or eliminate the --data-binary option and make it a form field (@davidovich)?

curl -F "repo=org1/repo1" -F "[email protected]" http://localhost:8080/api/charts

?
cc @alexei-led @itaysk

Feature Request: API for retrieving individual files from a chart

GET /api/charts/mychart/0.1.0/files/<file>

Required for serving up information relevant to a user installing a chart via a UI.

Separate web handlers from processing

For example getIndexFileRequestHandler() would delegate to something like getIndexFile(orgName, repoName, prefix), and this method would contain only the objects processing.

This will allow for better unit testing in the long run, and cleanly isolate the details of the web framework.

Should be able to specify different basic auth username/pass per tenant

@goruha @itaysk we have chatted about this.
This will likely need to be fixed by introducing a config file and/or config database

Ability to supply custom webhook for post-upload etc.

cc @verchol @itaysk @olegs-codefresh

Ingress and tls errors while installing new chart

I try to install the latest version of chartmuseum, but getting errors about the ingress.

Helm version: v2.8.1
Host: GCP
Kubernetes: v1.9.3-gke.0

Command:
helm install --name chartmuseum -f custom.yaml incubator/chartmuseum

Custom.yaml:

ingress:
  enabled: true

  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: 'true'

  hosts:
    chartmuseum.my-domain.com:
      - /charts
      - /index.yaml

  tls:
    secretName: chartmuseum-my-domain-tls
    hosts:
      - chartmuseum.my-domain.com

error:
Error: release chartmuseum failed: Ingress in version "v1beta1" cannot be handled as a Ingress: v1beta1.Ingress: Spec: v1beta1.IngressSpec: TLS: []v1beta1.IngressTLS: ReadArrayCB: expect [ or n, but found: {, parsing 621 ...}],"tls":{... at {"apiVersion":"extensions/v1beta1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"nginx","kubernetes.io/tls-acme":"true","nginx.ingress.kubernetes.io/rewrite-target":"/"},"labels":{"app":"chartmuseum","chart":"chartmuseum-0.4.4","heritage":"Tiller","release":"chartmuseum"},"name":"chartmuseum-chartmuseum","namespace":"default"},"spec":{"rules":[{"host":"chartmuseum.my-domain.com","http":{"paths":[{"backend":{"serviceName":"chartmuseum-chartmuseum","servicePort":8080},"path":"/charts"},{"backend":{"serviceName":"chartmuseum-chartmuseum","servicePort":8080},"path":"/index.yaml"}]}}],"tls":{"hosts":["chartmuseum.my-domain.com"],"secretName":"chartmuseum-my-domain-tls"}}}

Root url not using authentication when API is

It seems like the root / isn't using authentication when the /api requires it. Is this expected?

I see there is work going on in #59 and #64 and I'm guessing this is vestigial from #29 when the root was the healthcheck.

Is there a reason we leave the / unauthenticated?

Chartmuseum should have it's helm chart

This would allow easy installation in a kubernetes cluster.

Upgrade to Helm 2.8.2

https://github.com/kubernetes/helm/releases/tag/v2.8.2

Missing hint in docu for configuration via environment variables

Due to eg Ansible has no native support for passing command parameters into the docker container I have to use a config file or environment variables (which is easily done in Ansible). After digging into the entrypoint I saw you are fine with environment variables.

A small hint in the docu would be awesome.

make repo subdirectroy of multitenancy optional

Right now, the current multitenancy design mandates a structure in this style: org1/repoa, org2/repoa. While I still think two levels are a good idea in a centralized hosting scenario, I also think that it might be overkill for a corporate scenario where only one chartmuseum is present and one level (the org level) would be used for different teams. It appears that the file structure of the repos could be relaxed when the org separation is enough for simple use cases.

The two levels could be useful for these corporate teams, for providing something like dev / staging / prod, but can also be too fine-grained for a team only wanting a separate namespace.

This issue is opened to discuss the merits of an optional two level separation.

Proposal: Support for Azure Blob Storage

I'd like to see Azure Blob Storage as an option for the storage backend.

fatal error: concurrent map read and map write

When attempting to launch Chartmuseum we sometimes get the error fatal error: concurrent map read and map write.

Observed with both v0.1.0 and v0.2.0.

Running on Ubuntu 16.04 using Systemd with the below service configuration:

[Unit]
Description=Charmuseum service
After=network.target
After=systemd-user-sessions.service
After=network-online.target


[Service]
ExecStart=/opt/chartmuseum/chartmuseum --port=9001 --storage="amazon" --storage-amazon-bucket="my-bucket" --storage-amazon-prefix="" --storage-amazon-region="eu-west-1"

[Install]
WantedBy=multi-user.target

Log file:
chartmuseum.log

Multitenant server should serve multiple Helm Chart Repositories (readonly)

Continuing conversation started in #53 ...

When providing the --multitenant flag, ChartMuseum should act as multiple Helm Chart Repositories.

This issue covers implementing the following routes:

• GET /r/<org>/<repo>/index.yaml - retrieved when you run helm repo add chartmuseum http://localhost:8080/<org>/<repo>
• GET /r/<org>/<repo>/charts/mychart-0.1.0.tgz - retrieved when you run helm install chartmuseum/mychart
• GET /r/<org>/<repo>/charts/mychart-0.1.0.tgz.prov - retrieved when you run helm install with the --verify flag

Contents of each index.yaml will be determined by a nested directory in the storage backend. For example, if your storage looks like

charts
├── org1
│   ├── repoa
│   │   └── nginx-ingress-0.9.3.tgz
├── org2
│   ├── repob
│   │   └── chartmuseum-0.4.0.tgz

then an index.yaml with nginx-ingress-0.9.3.tgz will be available at the route /r/org1/repoa/index.yaml, and another index.yaml with chartmuseum-0.4.0.tgz will be available at the route /r/org2/repob/index.yaml etc.

This does not include caching (for now)

Multitenant server should use cache

Multitenant server is currently generating index.yaml upon every request, should be switched to use the cache

Question: vSphere Cloud Provider storage

Hi,

The documentation mentions Google Cloud Storage, Amazon S3, and Microsoft Azure Blob Storage.

Am I correct in assuming VCP storage would work as well?

Unable to start docker image

I believe that more details about how the tool woks is needed:
[1] What is the basic set of IAM permissions needed to work with this?
[1] Will the tool work with aws profiles (as per the existing example mounting ~/.aws in the docker image)
[1] How is the bucket accessed? Is the data replicated and then served?

Example that didn't work for me, but worked for calling the API:
policy attached to the assumed role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": "arn:aws:s3:::*"
        }
    ]
}

~/.aws/config contains:

[profile default]
role_arn = arn:aws:iam::00redacted000:role/ReadCharts
source_profile = default

~/.aws/credentials contains the standard credentials set.

commad used: docker run -p 8080:8080 -v ~/.aws:/root/.aws:ro chartmuseum/chartmuseum:latest --debug --port=8080 --storage="amazon" --storage-amazon-bucket="mycompany-helmcharts" --storage-amazon-prefix="" --storage-amazon-region="eu-central-1"

error:

2017-10-05T09:45:33.255Z	DEBUG	chartmuseum/server.go:166	Acquiring storage cache lock
2017-10-05T09:45:33.255Z	DEBUG	chartmuseum/server.go:168	Storage cache lock acquired
2017-10-05T09:45:33.613Z	DEBUG	chartmuseum/server.go:170	Releasing storage cache lock
AccessDenied: Access Denied
	status code: 403, request id: CxxxxredactedxxxxBA, host id: c1EDzxxxxxxxredactedxxxxxxx7X+e0xxxxxxxxxRlMl8=

Add possibility to post form data

Hi,

Would you be open to the idea of also supporting form data posts? With it, it would be possible to upload a chart by doing something like:

$ curl --form "chartfile=@/path/to/chart.tgz" ...

Customizable URL for the info page

I'm using chartmuseum in a Docker container behind a reverse proxy.

I've set the --chart-url option, so the generated URLs in the index.yaml are correct.

However, the info page (when accessing the domain with a browser) shows the client IP instead:

To add this as a local chart repository, please run the following command:
helm repo add chartmuseum https://10.11.12.13

It would be nice to have the URL in there also customizable.

Thanks!

Single tenant server, --multitenant flag should be removed

Once multitenant server is ready for prime time, it should be made the only server package. Singletenancy is supported in the multitenancy via --depth=0.

proposal: Add X-Request-Id header

With recent changes (#19) each request is assigned a numeric "RequestId" in order to easily group log lines tied to a request.

My suggestion is to take this one step further, and send the RequestId to the client in theX-Request-Id HTTP header for further debugging, correlating client-side requests to associated log lines.

I'd also like to propose using a UUID instead of integer to prevent collisions across replicas.

This gin middleware seems to do everything we need: https://github.com/atarantini/ginrequestid

In addition, we may want to discuss changing the format of log lines, i.e. should we prefix every line with this long UUID, or make it a k/v similar to "method": "GET"?

@cjauvin @davidovich thoughts?