Date   

Chart Repo Management UI (ChartMuseum UI)

Josh Dolitsky
 

I've talked with a number of people recently about a potential ChartMuseum UI.

This is not to be confused with the Monocular project, which is solving the issue of chart discovery across a distributed set of chart repos, all managed and deployed differently. This is more about enabling the hosting and management of your own chart repo(s).

Here is a proposed list of features the UI could provide (some of which require significant backend work):

- Login with basic auth credentials
- Login via third-party
- Create new organizations
- Create new repos
- Assign various roles to my team members: member/admin of an organization, ability to view/administer a repo, ability to create/read/update/delete charts to/from a specific repo
- List all charts in repo
- List all versions of a chart
- Download charts
- Upload charts
- Delete charts
- Search for charts
- Display the chart's README
- Mark my repo as public vs private

I've opened a GitHub issue to start the discussion, please add your feedback here: https://github.com/helm/chartmuseum/issues/150

Thanks!

Josh Dolitsky


What resources to apply templated fullname for metadata.name?

sean.glover@...
 

Hi,

I'm building a helm chart that I would eventually like to submit to the kubeapps repository for consideration.  While reviewing the Review Guidelines in kubernetes/charts there's a section about Names and Labels which states that all resource templates should follow some conventions.

Resources and labels should follow some conventions. The standard resource metadata should be this:
name: {{ template "myapp.fullname" . }}
labels:
  app: {{ template "myapp.name" . }}
  chart: {{ template "myapp.chart" . }}
  release: {{ .Release.Name }}
  heritage: {{ .Release.Service }}

The `myapp.fullname` template function in this case will be used to define a `metadata.name` that concatenates the helm release name and the chart name.  My question is when is it appropriate to define `metadata.name` in this manner?  After browsing several charts in kubeapps repositories I noticed inconsistency regarding this requirement.

More specifically, for a chart that deploys service accounts, role's, role bindings, CRD's, and deployments, which of these resource types should use the fullname template function for their `metadata.name`?

Regards,
Sean

--
Senior Software Engineer, Lightbend, Inc.




Re: Helm Chart Kubernetes Versioning

Adam Kaplan
 

Besides the capabilities object for Kubernetes versions, is there a way to decipher between Kubernetes and OpenShift versions?

I don't think Helm has any means of obtaining the OpenShift version, as this is usually obtained via the openshift CLI (`oc version`). Doesn't look like the Cababilities object only supports data on Kube and Tiller.

As an FYI OpenShift versions tend to track the underlying Kubernetes version it distributes (3.9 distributes k8s 1.9, 3.7 distributes 1.7, etc.).


On Thu, Jul 5, 2018 at 2:09 PM Matt Farina <matt@...> wrote:
> Besides the capabilities object for Kubernetes versions, is there a way to decipher between Kubernetes and OpenShift versions?

I’m not familiar enough with OpenShift to be able to know.

As CRDs, and their versions, take off I can imagine the landscape for “feature” or some other form of detection taking off.


-- 
Matt Farina
mattfarina.com





--

ADAM KAPLAN

SENIOR SOFTWARE ENGINEER - OPENSHIFT

Red Hat

100 E Davie St Raleigh, NC 27601 USA

adam.kaplan@...    T: +1-919-754-4843     IM: adambkaplan


Re: Helm Chart Kubernetes Versioning

Matt Farina
 

> Besides the capabilities object for Kubernetes versions, is there a way to decipher between Kubernetes and OpenShift versions?

I’m not familiar enough with OpenShift to be able to know.

As CRDs, and their versions, take off I can imagine the landscape for “feature” or some other form of detection taking off.


-- 
Matt Farina
mattfarina.com




Re: Helm Chart Kubernetes Versioning

wnatasha@...
 

Thank you for this information, Matt!

Besides the capabilities object for Kubernetes versions, is there a way to decipher between Kubernetes and OpenShift versions?

--
Natasha


Re: Helm Chart Kubernetes Versioning

Matt Farina
 

There is a Capabilities object available in Charts that has some information about the Kubernetes cluster including the version. You can use this to detect different Kuberentes versions and handle them differently.

Here’s an example used in a helper file. If you search in the charts repo for Capabilities you can find other examples.

Note, in the semver comparison example there is a -0 on the end of the version. Adding a pre-release in causes pre-release versions of Kubernetes to be supported in comparisons. This is important if you run in some places (e.g., GKE) where they use pre-releases to denote their environmental build rather than build metadata. They are breaking from the semver spec so the -0 allows us to work around it.

-- 
Matt Farina
mattfarina.com




Helm Chart Kubernetes Versioning

wnatasha@...
 

How do Helm charts handle differences in K8S API objects between different K8S/OpenShift versions? For example, for the apiVersion parameter, is there a way for Helm to know what version to put in depending on what version of K8S or OpenShift they have?


Re: Upgrade with rolling restart

Simon Fontana Oscarsson
 

Never mind. I just added RollingUpdate as my updateStrategy and it worked perfectly. Sorry for the
white noise.

--
SIMON FONTANA OSCARSSON
Software Developer

Ericsson
Ölandsgatan 1
37133 Karlskrona, Sweden
simon.fontana.oscarsson@...
www.ericsson.com

On tor, 2018-06-28 at 13:32 +0200, Simon Fontana Oscarsson wrote:
Hi,

I have a statefulset as a helm chart. When doing helm upgrade I would like to perform a rolling
restart of all pods. Is this possible with just helm? Is there a better workaround than performing
a
kubectl rolling-update after helm upgrade?


Upgrade with rolling restart

Simon Fontana Oscarsson
 

Hi,

I have a statefulset as a helm chart. When doing helm upgrade I would like to perform a rolling
restart of all pods. Is this possible with just helm? Is there a better workaround than performing a
kubectl rolling-update after helm upgrade?

--
SIMON FONTANA OSCARSSON
Software Developer

Ericsson
Ölandsgatan 1
37133 Karlskrona, Sweden
simon.fontana.oscarsson@...
www.ericsson.com


Community Repo Moved

Matt Farina
 

Now that Helm has moved to the CNCF we are starting to move repositories to the helm organization. The first to move is the Helm community repo which is now at github.com/helm/community 

It will be a little while before we move the Helm and Charts repos because of the way dependencies work. We have some things to work out. Some of the other supporting repositories will be moving in the next couple weeks.

-- 
Matt Farina
mattfarina.com




Re: How to override the default helm chart values in values.yaml using hapi?

benjamin <benjamin_wang@...>
 

 

I tried to use command “helm install —set app1.key1=abc my chart”, and it worked. So I read the source code helm command, eventually I figured out the root cause.

The structure of the values map should be hierarchical.

Previously the value map was created with the following code,

 

Values := make(map[string]interface{})

values[“app1.key1”] = “abc”

 

The above code isn’t correct, and it should be something as below,

Base := make(map[string]interface{})

InnerApp1 = make(map[string]interface{})

innerApp1[“key1”] = “abc”

base[“app1”] = innerApp1 


Re: How to override the default helm chart values in values.yaml using hapi?

benjamin <benjamin_wang@...>
 

Note that I did not use helm client, instead, I use gRPC API to communicate with tiller server directly. 

 

I just reviewed the source code of helm client. It just configures the InstallReleaseRequest.Values with the overrides values. I followed the same logic,  so I just updated InstallReleaseRequest.Values with the override values directly.  The new source code is something as below, but it did not work either. The helm chart can be created successfully, but the POD still uses the default values defined in values.yaml in the chart instead of the override values. Can someone help to point out what’s the reason? 

 

func deploy(tillerEndpoint, helmChartDir, helmChartName string, overrideValues map[string]interface{}) error {

conn, err := grpc.Dial(tillerEndpoint, grpc.WithInsecure())

defer conn.Close()

tillerClient := services.NewReleaseServiceClient(conn)

helmChart, err := chartutil.Load(helmChartDir)

cc := chart.Config{ Raw:    helmChart.Values.Raw }

         If overrideValues != nil {

vals, err := chartutil.Values(overrideValues).YAML()

                cc = chart.Config{Raw: vals }

  }

req := &services.InstallReleaseRequest{

Chart:        helmChart,

Values:       &cc,

Name:         helmChartName,

Namespace:    "default",

DryRun:       false,

DisableHooks: true,

}

err = chartutil.ProcessRequirementsEnabled(req.Chart, req.Values)

err = chartutil.ProcessRequirementsImportValues(req.Chart)

_, err = tillerClient.InstallRelease(helm.NewContext(), req)

return err

}


Re: How to override the default helm chart values in values.yaml using hapi?

Matt Fisher <matt.fisher@...>
 

If you want to override values, you'll want to add your values as a ValueOverride option to InstallRelease. An example can be found within Draft: https://github.com/Azure/draft/blob/9e1f18aa6d9bd382bf9602b66eeb870b99213f8b/pkg/builder/builder.go#L411-L421


1504220459230_microsoft.png

Matthew Fisher, Caffeinated Software Engineer

Microsoft Azure Platform

Nanoose Bay, BC Canada

Emailmatt.fisher@...

Phone: 1(250)937-1478


From: cncf-helm@... <cncf-helm@...> on behalf of benjamin via Lists.Cncf.Io <benjamin_wang=aliyun.com@...>
Sent: Tuesday, June 12, 2018 8:28 AM
To: cncf-helm@...
Cc: cncf-helm@...
Subject: [cncf-helm] How to override the default helm chart values in values.yaml using hapi?
 
I use the following code (golang) to deploy helm chart into kubernetes. I removed the error handling code for simplicity. 

The last parameter "values" is used to override the values of some fields defined in values.yaml . But after the chart is created, the values used by the POD are still the default values defined in values.yaml in the chart instead of the values included in the last parameter of the following function. What did I miss? Thanks!

func deploy(tillerEndpoint, helmChartDir, helmChartName string, values map[string]*chart.Value) error {
conn, err := grpc.Dial(tillerEndpoint, grpc.WithInsecure())
defer conn.Close()
tillerClient := services.NewReleaseServiceClient(conn)
helmChart, err := chartutil.Load(helmChartDir)
cc := chart.Config{
Raw:    helmChart.Values.Raw,
Values: values,
}
req := &services.InstallReleaseRequest{
Chart:        helmChart,
Values:       &cc,
Name:         helmChartName,
Namespace:    "default",
DryRun:       false,
DisableHooks: true,
}
err = chartutil.ProcessRequirementsEnabled(req.Chart, req.Values)
err = chartutil.ProcessRequirementsImportValues(req.Chart)
_, err = tillerClient.InstallRelease(helm.NewContext(), req)
return err
}


How to override the default helm chart values in values.yaml using hapi?

benjamin <benjamin_wang@...>
 

I use the following code (golang) to deploy helm chart into kubernetes. I removed the error handling code for simplicity. 

The last parameter "values" is used to override the values of some fields defined in values.yaml . But after the chart is created, the values used by the POD are still the default values defined in values.yaml in the chart instead of the values included in the last parameter of the following function. What did I miss? Thanks!

func deploy(tillerEndpoint, helmChartDir, helmChartName string, values map[string]*chart.Value) error {
conn, err := grpc.Dial(tillerEndpoint, grpc.WithInsecure())
defer conn.Close()
tillerClient := services.NewReleaseServiceClient(conn)
helmChart, err := chartutil.Load(helmChartDir)
cc := chart.Config{
Raw:    helmChart.Values.Raw,
Values: values,
}
req := &services.InstallReleaseRequest{
Chart:        helmChart,
Values:       &cc,
Name:         helmChartName,
Namespace:    "default",
DryRun:       false,
DisableHooks: true,
}
err = chartutil.ProcessRequirementsEnabled(req.Chart, req.Values)
err = chartutil.ProcessRequirementsImportValues(req.Chart)
_, err = tillerClient.InstallRelease(helm.NewContext(), req)
return err
}


Re: Prevent an accidental helm delete

Bryan Rosander
 

If your cluster is using RBAC, you could remove the tiller's RoleBinding (or at least its delete permissions) to prevent the tiller from carrying out an unintended delete.

Thanks,
Bryan


Re: Prevent an accidental helm delete

Matt Fisher <matt.fisher@...>
 

Hey Victor,

I'm not aware of a way to do this right now, but a --prompt option flag has been suggested previously (though for helm install). We'd be more than happy to see a PR to add that flag! We'd just have to ensure that it's turned off by default for backwards compatibility. Feel like hacking up that feature for Helm? 😊



1504220459230_microsoft.png

Matthew Fisher, Caffeinated Software Engineer

Microsoft Azure Platform

Nanoose Bay, BC Canada

Emailmatt.fisher@...

Phone: 1(250)937-1478


From: cncf-helm@... <cncf-helm@...> on behalf of victor.buciuc@... <victor.buciuc@...>
Sent: Monday, June 11, 2018 3:05 PM
To: cncf-helm@...
Subject: [cncf-helm] Prevent an accidental helm delete
 
Hi,

Is there a way to prevent an accidental helm delete?

Regards,
Victor.


Prevent an accidental helm delete

victor.buciuc@...
 

Hi,

Is there a way to prevent an accidental helm delete?

Regards,
Victor.


Re: Linking external files to the values.yaml

kavindu175@...
 

Hi Matt,

Thank you for the advice and I will follow that. Can you place send some documentations regarding --set.
And yes we can close that GitHub issue.

Thank you,
Kavindu


Re: Linking external files to the values.yaml

Matt Fisher <matt.fisher@...>
 

Hey Kavindu,

Up until very recently there was no way to reference files external to the helm chart asides from using invocations like `--set foo=$(cat myfile)`. However, there is a PR out there to make this simpler by adding a new --set-file flag: https://github.com/kubernetes/helm/pull/3758

Until then, using --set is your best bet.

Is it all right if we go ahead and close https://github.com/kubernetes/helm/issues/4131 and carry the conversation here? It's nice to keep a conversation in one place.

Thanks!


1504220459230_microsoft.png

Matthew Fisher, Caffeinated Software Engineer

Microsoft Azure Platform

Nanoose Bay, BC Canada

Emailmatt.fisher@...

Phone: 1(250)937-1478


From: cncf-kubernetes-helm@... <cncf-kubernetes-helm@...> on behalf of kavindu175@... <kavindu175@...>
Sent: Monday, May 28, 2018 3:19 AM
To: cncf-kubernetes-helm@...
Subject: [cncf-kubernetes-helm] Linking external files to the values.yaml
 
Hi,

Currently, I am working on deploying MySQL using helm package. In that scenario, I want to add some custom configuration files and initialization SQL file. According to the details which are provided on GitHub, we have to paste the content of all the configuration files and all the initialization SQL files into the values.yaml file. But in my case, I have a very big initialization SQL file and it is hard to paste it on the values.yaml file. 

Therefore, is there a way to link an external file or file path to the values.yaml or is there some other solution for this issue? 
Kindly appreciated your inputs on this issue.

Thank you,
Kavindu
 




Linking external files to the values.yaml

kavindu175@...
 

Hi,

Currently, I am working on deploying MySQL using helm package. In that scenario, I want to add some custom configuration files and initialization SQL file. According to the details which are provided on GitHub, we have to paste the content of all the configuration files and all the initialization SQL files into the values.yaml file. But in my case, I have a very big initialization SQL file and it is hard to paste it on the values.yaml file. 

Therefore, is there a way to link an external file or file path to the values.yaml or is there some other solution for this issue? 
Kindly appreciated your inputs on this issue.

Thank you,
Kavindu
 



401 - 420 of 454