1. cncf-helm@lists.cncf.io
  2. Messages
   Date   
Helm : referencing the parent template field in sub chart.

lmadan@...
 
Edited

Hi all, i have a quick question. I have the chart
hierarchy

-- parentChart
  -- template
    -- _helpers.tpl— charts
  -- charts
    -- chart1
      -- template
        -- _helpers.tpl
    --  chart2
       -- template
         -- _helpers.tpl

Values.yaml in parentChart has
 global:
   somekey: values
   someotherpath: someValue

  common:
    mypath: someValue
    someMoreKeys: andSomeMoreValues

In parent chart i have defined
{{- define “mypath" -}}
{{- if .Values.common -}}
{{- required "common.mypath is required !" .Values.common.mypath -}}
{{- else -}}
{{- required ".Values.global.someotherpath is required !" .Values.global.someotherpath}}
{{- end -}}
{{- end -}}And now in chart1 i am trying to refer{{- define "mypath" }}
from: parentChart
{{- end -}}{{- define “copyMyPath” -}}
{{- include "mypath" "need value"}}
{{- end -}}I am getting below errortemplate: parentChart/charts/chart1/templates/deployment.yaml:37:20: executing “parentChart/charts/chart1/templates/deployment.yaml" at <include “copyMyPath” .>: error calling include: template: parentChart/charts/chart1/templates/_helpers.tpl:43:4: executing “copyMyPath" at <include “mypath” "need value">: error calling include: template: parentChart/templates/_helpers.tpl:112:14: executing “mypath” at <.Values.common>: can't evaluate field Values in type string

Am i missing something ?

Idea is i want to refer what's defined in parent chart template

Any help on this really appreciated


I posted the message the message on #helm-users slack channel, but haven't got any response.
Re: Lua Technical Discussion

Alistair Lowe
 

Hi Matt,

Thanks for the great briefing, it sounds like the biggest sticking-point in my suggestion is that AFAIK Squirrel doesn't have a Go implementation.

It shares a lot in common with Lua and was inspired by it but addressed a few key points at the time:
  • A much more familiar C-based syntax with native JSON notation support.
  • Better OO support.
  • Predictable Garbage Collection (was targeted at gaming).
You'll still find it today in Valve's Steam engine and Electric Imp's IoT platform and like Lua, it covers most of the points you've listed, it's portable, easily embeddable, small footprint, safer, free and open source.

My motivation for suggesting this was simply the familiarity of the syntax for an end-user, Lua may be 24th in the PYPL popularity list but that only accounts for a 0.31% share, which has been dropping each year, and its syntax style is fairly distant from the more popular languages. Squirrel is so close to Javascript and other C-based languages that a large number of users could run with it after a few minutes (once you realise 'local' instead of 'let'), much as I did when first picking it up. An example of the Syntax:

---
local myVar = 10.5;
local myString = "hi";
local myVerbatimString = @"Lots of escape characters will be printed \n\n\n\n\n\n";
local myTable1 = { test = 1, test2 = 2 };
local myTable2 = { "test": 1, "test2": "2" }; // JSON notation version (also note C-based comments, including block comments)
local myArray = [1, 2, 3, "hi"];

local myFunc = function(a,b) {
   if (a > b) {
      return 1;
   } else {
      return 0;
   }
}

local myLambda = @(a,b) a+b;

foreach (key, value in myTable1) {
   myTable[key] = value + 1;
}

function someFunction()
{
   return "hi";
}

class MyClass
{
   _privateParam = 10;

   constructor() { }

   function myFunc() { return _privateParam; }
}

local myInstance = myClass();
---


Many thanks,
Alistair Lowe


On Thu, Mar 12, 2020 at 6:10 PM Matt Fisher <Matt.Fisher@...> wrote:
We were looking to use Lua as a pre- and post-hook event system when charts were being rendered.

The post-render hook introduced in Helm 3.1 seems to handle most of the use cases the Lua event system would enable, so the need to implement a Lua-based event model was de-prioritized.

Lua was chosen over other languages for the following reasons:
  • portability (can be used on all devices)
  • designed to be embedded in other programs (simple sandboxing model)
  • it's an incredibly simple language (usually means there are less security risks)
  • the compiler and runtime take up a very small footprint, both in terms of overhead performance and code size
  • it's free and open source
  • it's being used in production in many software projects. NGINX famously loads Lua modules, allowing users to extend its capabilities.
  • there are several reference implementations of Lua VMs written in Go:
More information on the implementation details (as well as the use cases we were targeting) can be found in the Helm 3 proposal for the event-driven model. The Lua plugin proposal was another potential area we could use Lua.

I guess I have two questions:
  • What use case are you attempting to solve with this proposal?
  • Are there any Squirrel VMs written in Go?

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada

From: cncf-helm@... <cncf-helm@...> on behalf of Alistair Lowe via Lists.Cncf.Io <alistair=skyiot.co.uk@...>
Sent: Wednesday, March 11, 2020 4:42 PM
To: cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] Lua Technical Discussion
 
Hi guys,

I'm interested in the move to supporting Lua templates, is there a technical discussion or documentation discussing the reasoning behind Lua as a language choice?

I would like to put forward Squirrel-lang as a potencial alternative, it is easily embedded and small footprint like Lua but features a more familiar and intuative C-based syntax, very close to Java script and has native JSON support with good end-user documentation.

I'd like to understand more around the reasoning behind Lua and why it was selected to understand if this propos is a sensible one.

Many thanks

Re: Is it possibe to create yaml object in helm from file

Fox, Kevin M <Kevin.Fox@...>
 

Probably not the right forum to ask usage questions on. Maybe try the #helm-users kubernetes slack channel in the future. But:
{{- $lists := .Files.Get "files/test.yaml" | fromYaml }}
{{- range $element := $lists.list}}
---
apiVersion: batch/v1
kind: Job
metadata:
name: {{ $element }}
{{- end }}

________________________________________
From: cncf-helm@lists.cncf.io <cncf-helm@lists.cncf.io> on behalf of lmadan@alumni.usc.edu <lmadan@alumni.usc.edu>
Sent: Thursday, March 12, 2020 4:37 PM
To: cncf-helm@lists.cncf.io
Subject: [cncf-helm] Is it possibe to create yaml object in helm from file

I want to iterate over the Yaml list which is defined in the file, and use it in Job. For example i have

test.yaml

list:
- first element
- second element

In _helpers.tpl i can define
something like

{{- define "mychart.list" -}}
{{ .Files.Get "test.yaml"| toYaml }}
{{- end }}

And then in Job i want do something like

{{- $lists := include "mychart.list" . }}
{{- range $element := $lists.list}}
apiVersion: batch/v1
kind: Job
metadata:


and then use the $element.

But when i am trying to do the dry-run with --debug it complains about

at <$lists.list>: can't evaluate field list in type string.

Looks like whole value is coming as string rather than Yaml, does it needs explicit call to Yaml parser ? If yes, is there a way to do that ?

BTW i have also tried various combinations of

{{- $lists := include "mychart.list" . | toYaml }}

or loading the file inline, but none of them helps.

I can put the list in Values.yaml, but don't want to do that purposely.


Any help is really appreciated.
Is it possibe to create yaml object in helm from file

lmadan@...
 

I want to iterate over the Yaml list which is defined in the file, and use it in Job. For example i have

test.yaml

    list:
      - first element
      - second element

In _helpers.tpl i can define
something like

{{- define "mychart.list" -}}
{{ .Files.Get "test.yaml"| toYaml }}
{{- end }}

And then in Job i want do something like

    {{- $lists  := include "mychart.list" . }}
    {{- range $element := $lists.list}}
    apiVersion: batch/v1
    kind: Job
    metadata:


and then use the $element.

But when i am trying to do the dry-run with --debug it complains about

at <$lists.list>: can't evaluate field list in type string.

Looks like whole value is coming as string rather than Yaml, does it needs explicit call to Yaml parser ? If yes, is there a way to do that ?

BTW i have also tried various combinations of

    {{- $lists  := include "mychart.list" . | toYaml }}

or loading the file inline, but none of them helps.

I can put the list in Values.yaml, but don't want to do that purposely.


Any help is really appreciated.
Re: Lua Technical Discussion

Matt Fisher <matt.fisher@...>
 

We were looking to use Lua as a pre- and post-hook event system when charts were being rendered.

The post-render hook introduced in Helm 3.1 seems to handle most of the use cases the Lua event system would enable, so the need to implement a Lua-based event model was de-prioritized.

Lua was chosen over other languages for the following reasons:
  • portability (can be used on all devices)
  • designed to be embedded in other programs (simple sandboxing model)
  • it's an incredibly simple language (usually means there are less security risks)
  • the compiler and runtime take up a very small footprint, both in terms of overhead performance and code size
  • it's free and open source
  • it's being used in production in many software projects. NGINX famously loads Lua modules, allowing users to extend its capabilities.
  • there are several reference implementations of Lua VMs written in Go:
More information on the implementation details (as well as the use cases we were targeting) can be found in the Helm 3 proposal for the event-driven model. The Lua plugin proposal was another potential area we could use Lua.

I guess I have two questions:
  • What use case are you attempting to solve with this proposal?
  • Are there any Squirrel VMs written in Go?

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada

From: cncf-helm@... <cncf-helm@...> on behalf of Alistair Lowe via Lists.Cncf.Io <alistair=skyiot.co.uk@...>
Sent: Wednesday, March 11, 2020 4:42 PM
To: cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] Lua Technical Discussion
 
Hi guys,

I'm interested in the move to supporting Lua templates, is there a technical discussion or documentation discussing the reasoning behind Lua as a language choice?

I would like to put forward Squirrel-lang as a potencial alternative, it is easily embedded and small footprint like Lua but features a more familiar and intuative C-based syntax, very close to Java script and has native JSON support with good end-user documentation.

I'd like to understand more around the reasoning behind Lua and why it was selected to understand if this propos is a sensible one.

Many thanks

Lua Technical Discussion

Alistair Lowe
 

Hi guys,

I'm interested in the move to supporting Lua templates, is there a technical discussion or documentation discussing the reasoning behind Lua as a language choice?

I would like to put forward Squirrel-lang as a potencial alternative, it is easily embedded and small footprint like Lua but features a more familiar and intuative C-based syntax, very close to Java script and has native JSON support with good end-user documentation.

I'd like to understand more around the reasoning behind Lua and why it was selected to understand if this propos is a sensible one.

Many thanks
Re: Helm unit tests

Simon Fontana Oscarsson
 

Thank you Gareth. At a first glance it looks good and I will surely try it out. 

-- 
SIMON FONTANA OSCARSSON
Software Developer

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

On ons, 2020-02-26 at 15:51 +0000, Gareth Rushgrove wrote:
As one of the maintainers I'm biased, but try out Conftest
https://protect2.fireeye.com/v1/url?k=e368c855-bfe21d50-e36888ce-861010bc36ff-8633b5071164f958&q=1&e=b790fd3f-f57a-40c5-8e65-dd11951c6ffe&u=https%3A%2F%2Fgithub.com%2Finstrumenta%2Fconftest

We have a Helm plugin which makes this easier too
https://protect2.fireeye.com/v1/url?k=c7f50a60-9b7fdf65-c7f54afb-861010bc36ff-879dd0a6072a1d53&q=1&e=b790fd3f-f57a-40c5-8e65-dd11951c6ffe&u=https%3A%2F%2Fgithub.com%2Finstrumenta%2Fhelm-conftest

Gareth

On Wed, 26 Feb 2020 at 15:48, Simon Fontana Oscarsson via
Lists.Cncf.Io <simon.fontana.oscarsson=ericsson.com@...>
wrote:



Hi,

Are there any good options for writing unit tests for Helm charts? My use case is that I want to test that, when setting a parameter, the correct changes are applied to the chart.

I've looked a bit at the helm-unittest project (https://protect2.fireeye.com/v1/url?k=3c2da40c-60a77109-3c2de497-861010bc36ff-58d3fe68ccadf71f&q=1&e=b790fd3f-f57a-40c5-8e65-dd11951c6ffe&u=https%3A%2F%2Fgithub.com%2Flrills%2Fhelm-unittest) and it looks good enough. Unfortunately it is no longer maintained, last commit was almost a year ago and many issues are left unanswered. For example it doesn't have Helm v3 support (yes, there is a PR but I don't want to apply hotfixes and maintain the project myself).
Are there any other good projects with healthy community support for Helm chart unit tests?

--

SIMON FONTANA OSCARSSON
Software Developer

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

?
smime.p7s

Re: Helm unit tests

Gareth Rushgrove
 

As one of the maintainers I'm biased, but try out Conftest
https://github.com/instrumenta/conftest

We have a Helm plugin which makes this easier too
https://github.com/instrumenta/helm-conftest

Gareth

On Wed, 26 Feb 2020 at 15:48, Simon Fontana Oscarsson via
Lists.Cncf.Io <simon.fontana.oscarsson=ericsson.com@lists.cncf.io>
wrote:


Hi,

Are there any good options for writing unit tests for Helm charts? My use case is that I want to test that, when setting a parameter, the correct changes are applied to the chart.

I've looked a bit at the helm-unittest project (https://github.com/lrills/helm-unittest) and it looks good enough. Unfortunately it is no longer maintained, last commit was almost a year ago and many issues are left unanswered. For example it doesn't have Helm v3 support (yes, there is a PR but I don't want to apply hotfixes and maintain the project myself).
Are there any other good projects with healthy community support for Helm chart unit tests?

--

SIMON FONTANA OSCARSSON
Software Developer

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

--
Gareth Rushgrove
@garethr

garethr.dev
devopsweekly.com
Helm unit tests

Simon Fontana Oscarsson
 

Hi,

Are there any good options for writing unit tests for Helm charts? My use case is that I want to test that, when setting a parameter, the correct changes are applied to the chart.

I've looked a bit at the helm-unittest project (https://github.com/lrills/helm-unittest) and it looks good enough. Unfortunately it is no longer maintained, last commit was almost a year ago and many issues are left unanswered. For example it doesn't have Helm v3 support (yes, there is a PR but I don't want to apply hotfixes and maintain the project myself).
Are there any other good projects with healthy community support for Helm chart unit tests?

-- 
SIMON FONTANA OSCARSSON
Software Developer

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

?
smime.p7s

Re: Helm v3.1.0

Matt Farina
 

s/not/now .... Helm v3.1.0 has NOW been released. Thanks for catching my typo Jimmy.

On Thu, Feb 13, 2020, at 12:30 PM, Matt Farina wrote:
Helm v3.1.0 has not been released. You can read about it at https://github.com/helm/helm/releases/tag/v3.1.0

There was about 3 months between the release of 3.0.0 and 3.1.0. The release of 3.0.0 was a large effort and this was followed conferences and holidays. We are now back into the swing of things and releases should be a little more regular.

Regards,
Matt Farina
Helm v3.1.0

Matt Farina
 

Helm v3.1.0 has not been released. You can read about it at https://github.com/helm/helm/releases/tag/v3.1.0

There was about 3 months between the release of 3.0.0 and 3.1.0. The release of 3.0.0 was a large effort and this was followed conferences and holidays. We are now back into the swing of things and releases should be a little more regular.

Regards,
Matt Farina
Re: Urgent: Helm CNCF webinar

Joe Thompson
 

I created the Helm 2 Weave Scope chart, and I’ve been looking at it in light of the recent GA of Helm 3, and a lot of what I need to do with it is security-related:
 
* It needs version/default image updates
* It needs an update in how it runs with privileged access since that’s changed in underlying Kubernetes
* It uses the bats image called out in the Helm report for running its install tests (because I copied the test structure from another chart that used bats), so that could probably stand to change
* I need to sign it and find hosting for it so it can be deprecated from kubernetes/charts
 
I’d be happy to do some sort of self-review and update and use that as material to present during your webinar if you think that’d be useful. — Joe
Urgent: Helm CNCF webinar

Raghavan "Rags" N. Srinivas <rags@...>
 

Hi all:

Reaching out re: help for a CNCF webinar on Feb. 25th (date and time is final). There is flexibility WRT content. Will include the Helm report (see below) but will be great to have something more Helmish or Helm securityish as a lead in.

Since MattB and MattF did a webinar recently - https://www.cncf.io/webinars/a-conversation-about-helm-3/ might be best to do something a bit different around Helm Security perhaps. They also declined for the same reason and hence reaching out to the larger Helm contributor list.

Since we have to confirm the abstract, etc. early next week appreciate a prompt response.

Summary of ask: Is to participate in the webinar with Haley and Snyk (will be great to plug in your kubecon eu session or Helm related work here).

Thoughts?

Thanks!

Rags

---------- Forwarded message ---------
From: Raghavan "Rags" N. Srinivas <rags@...>
Date: Tue, Feb 4, 2020 at 6:20 PM
Subject: Urgent: Helm CNCF webinar
To: Matt Butcher <Matt.Butcher@...>, Matt Fisher <Matt.Fisher@...>, <rags@...>


Matt and Matt:

Hope you both are well?

Great opportunity here but need a quick turnaround (apologies for reaching out a bit late). I can reach out to the larger Helm group if needed (since this is somewhat time bound).

Hayley (my colleague) is doing a talk at Kubecon.


She also produced the following report.


she's also been invited by CNCF to do a webinar on Feb. 25th. 

I was suggesting a more general agenda than the report. I'll moderate. I'll work on title/abstract, etc. with inputs from everyone.

History of Helm and the Helm summit [Matt Butcher - https://www.infoq.com/news/2019/09/helm-butcher/]
Helm state of the union and roadmap [Matt Fisher - https://www.infoq.com/news/2019/11/helm3-matt-fisher/]
The untold tale of Helm Chart Security [Hayley]

Deadlines.

Abstract, title, speakers are due 2/11
Webinar starts with a sound check at 9:30 am PT on 2/25 and runs from 10-11.

Please confirm ASAP if interested (hope you are) and can we meet the deadlines and if you want to tweak the agenda?

Thanks!

Rags
Re: Helm 3 impersonation

Matt Fisher <matt.fisher@...>
 

This feature is being tracked in https://github.com/helm/helm/issues/5303. It is not currently available. However, the implementation details seem easy enough for someone new to the Helm code base to tackle as their first contribution.

Would you be interested in implementing that functionality?


1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada

From: cncf-helm@... <cncf-helm@...> on behalf of Ashik Mohammed via Lists.Cncf.Io <ashikmohammed=gmail.com@...>
Sent: Thursday, February 6, 2020 6:20 PM
To: cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] Helm 3 impersonation
 
Does helm 3 supports impersonation similar to ‘as’ in kubectl?

Helm 3 impersonation

Ashik Mohammed
 

Does helm 3 supports impersonation similar to ‘as’ in kubectl?
Re: Helm 3 "state"? Is there such a thing

Abhirama <abhirama@...>
 

Thank you very much, Fox and Kevin. That cleared up my confusion.


On Thu, Feb 6, 2020 at 1:35 AM Fox, Kevin M <Kevin.Fox@...> wrote:
As far as I can tell, the "state" is made up of:
* caches
* credentials
* repos

So long as your stateless job (k8s pod) adds whatever credentials it needs and repo's as part of the job you should be fine loosing the state dirs when the pod is destroyed.

Thanks,
Kevin

________________________________________
From: cncf-helm@... <cncf-helm@...> on behalf of Abhirama <abhirama@...>
Sent: Tuesday, February 4, 2020 8:46 PM
To: cncf-helm@...
Subject: [cncf-helm] Helm 3 "state"? Is there such a thing

Hi,

I'm sorry if the question comes across as too lame.

Now that Helm 3 is client-only, I understand that it stores "state" information along with the client in the directories determined by the environment variables  XDG_CACHE_HOME, XDG_CONFIG_HOME and XDG_DATA_HOME. As a result, if Helm were to run on "stateless" machines (say if it were to run on a k8s pod every time it's run), does it still need access to the state it maintains in the aforementioned directories?

I've gone through https://helm.sh/docs/faq/#improved-upgrade-strategy-3-way-strategic-merge-patches<https://protect2.fireeye.com/v1/url?k=8fc82a5b-d37d15e2-8fc8004e-0cc47adc5fce-21e70389bd088c24&q=1&e=47578958-1bc5-4e52-8ace-0cf551c00ea5&u=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23improved-upgrade-strategy-3-way-strategic-merge-patches> and https://helm.sh/docs/faq/#xdg-base-directory-support<https://protect2.fireeye.com/v1/url?k=63b63cd0-3f030369-63b616c5-0cc47adc5fce-2e0c98b88fbbb452&q=1&e=47578958-1bc5-4e52-8ace-0cf551c00ea5&u=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23xdg-base-directory-support> and wasn't able to completely iron out my confusion. My guess is that, during the 3-way merge, the mentioned "old manifest" is directly retrieved from the k8s master itself and that Helm doesn't store any release related information in the aforementioned directories.

I'd greatly appreciate your help in clarifying this.

Thanks,
Abhirama.

Re: Helm 3 "state"? Is there such a thing

Abhirama <abhirama@...>
 

Sorry, I meant to say "Thanks, Kevin and Matthew"!


On Thu, Feb 6, 2020 at 2:45 AM Matt Fisher <Matt.Fisher@...> wrote:
> My guess is that, during the 3-way merge, the mentioned "old manifest" is directly retrieved from the k8s master itself and that Helm doesn't store any release related information in the aforementioned directories.

Correct. State about the current release is stored server-side (in Kubernetes) as a Secret. The three-way merge patch pulls down this metadata, comparing it to the chart you are upgrading to (`helm upgrade release_name *CHART*`), and the live state.

Stuff stored in the XDG directories contain local setup information, such as
  • repositories you've added (`helm repo list`)
  • plugins you have installed
  • cached repository indices
  • cached charts pulled down from said repositories (either via `helm install` or `helm pull`)
It is entirely safe to run Helm from an ephemeral filesystem, such as a container. No state about what was installed in the cluster is stored locally.


Hope that answers your question.


1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada

From: cncf-helm@... <cncf-helm@...> on behalf of Fox, Kevin M via Lists.Cncf.Io <Kevin.Fox=pnnl.gov@...>
Sent: Wednesday, February 5, 2020 12:05 PM
To: Abhirama <abhirama@...>; cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] Helm 3 "state"? Is there such a thing
 
As far as I can tell, the "state" is made up of:
* caches
* credentials
* repos

So long as your stateless job (k8s pod) adds whatever credentials it needs and repo's as part of the job you should be fine loosing the state dirs when the pod is destroyed.

Thanks,
Kevin

________________________________________
From: cncf-helm@... <cncf-helm@...> on behalf of Abhirama <abhirama@...>
Sent: Tuesday, February 4, 2020 8:46 PM
To: cncf-helm@...
Subject: [cncf-helm] Helm 3 "state"? Is there such a thing

Hi,

I'm sorry if the question comes across as too lame.

Now that Helm 3 is client-only, I understand that it stores "state" information along with the client in the directories determined by the environment variables  XDG_CACHE_HOME, XDG_CONFIG_HOME and XDG_DATA_HOME. As a result, if Helm were to run on "stateless" machines (say if it were to run on a k8s pod every time it's run), does it still need access to the state it maintains in the aforementioned directories?

I've gone through https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23improved-upgrade-strategy-3-way-strategic-merge-patches&amp;data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&amp;sdata=iU6D6%2BlcJ52vp5P1NJbfmCSIKlqPNti%2B8ZLswWCFuxE%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23improved-upgrade-strategy-3-way-strategic-merge-patches&amp;data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&amp;sdata=iU6D6%2BlcJ52vp5P1NJbfmCSIKlqPNti%2B8ZLswWCFuxE%3D&amp;reserved=0> and https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23xdg-base-directory-support&amp;data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&amp;sdata=uXYvT8fSYoeGWHBP%2BGfzO%2BNC2zvrHBjPp0Y1Bgd91Ls%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23xdg-base-directory-support&amp;data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&amp;sdata=uXYvT8fSYoeGWHBP%2BGfzO%2BNC2zvrHBjPp0Y1Bgd91Ls%3D&amp;reserved=0> and wasn't able to completely iron out my confusion. My guess is that, during the 3-way merge, the mentioned "old manifest" is directly retrieved from the k8s master itself and that Helm doesn't store any release related information in the aforementioned directories.

I'd greatly appreciate your help in clarifying this.

Thanks,
Abhirama.
Re: Helm 3 "state"? Is there such a thing

Matt Fisher <matt.fisher@...>
 

> My guess is that, during the 3-way merge, the mentioned "old manifest" is directly retrieved from the k8s master itself and that Helm doesn't store any release related information in the aforementioned directories.

Correct. State about the current release is stored server-side (in Kubernetes) as a Secret. The three-way merge patch pulls down this metadata, comparing it to the chart you are upgrading to (`helm upgrade release_name *CHART*`), and the live state.

Stuff stored in the XDG directories contain local setup information, such as
  • repositories you've added (`helm repo list`)
  • plugins you have installed
  • cached repository indices
  • cached charts pulled down from said repositories (either via `helm install` or `helm pull`)
It is entirely safe to run Helm from an ephemeral filesystem, such as a container. No state about what was installed in the cluster is stored locally.


Hope that answers your question.


1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada

From: cncf-helm@... <cncf-helm@...> on behalf of Fox, Kevin M via Lists.Cncf.Io <Kevin.Fox=pnnl.gov@...>
Sent: Wednesday, February 5, 2020 12:05 PM
To: Abhirama <abhirama@...>; cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] Helm 3 "state"? Is there such a thing
 
As far as I can tell, the "state" is made up of:
* caches
* credentials
* repos

So long as your stateless job (k8s pod) adds whatever credentials it needs and repo's as part of the job you should be fine loosing the state dirs when the pod is destroyed.

Thanks,
Kevin

________________________________________
From: cncf-helm@... <cncf-helm@...> on behalf of Abhirama <abhirama@...>
Sent: Tuesday, February 4, 2020 8:46 PM
To: cncf-helm@...
Subject: [cncf-helm] Helm 3 "state"? Is there such a thing

Hi,

I'm sorry if the question comes across as too lame.

Now that Helm 3 is client-only, I understand that it stores "state" information along with the client in the directories determined by the environment variables  XDG_CACHE_HOME, XDG_CONFIG_HOME and XDG_DATA_HOME. As a result, if Helm were to run on "stateless" machines (say if it were to run on a k8s pod every time it's run), does it still need access to the state it maintains in the aforementioned directories?

I've gone through https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23improved-upgrade-strategy-3-way-strategic-merge-patches&amp;data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&amp;sdata=iU6D6%2BlcJ52vp5P1NJbfmCSIKlqPNti%2B8ZLswWCFuxE%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23improved-upgrade-strategy-3-way-strategic-merge-patches&amp;data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&amp;sdata=iU6D6%2BlcJ52vp5P1NJbfmCSIKlqPNti%2B8ZLswWCFuxE%3D&amp;reserved=0> and https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23xdg-base-directory-support&amp;data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&amp;sdata=uXYvT8fSYoeGWHBP%2BGfzO%2BNC2zvrHBjPp0Y1Bgd91Ls%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23xdg-base-directory-support&amp;data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&amp;sdata=uXYvT8fSYoeGWHBP%2BGfzO%2BNC2zvrHBjPp0Y1Bgd91Ls%3D&amp;reserved=0> and wasn't able to completely iron out my confusion. My guess is that, during the 3-way merge, the mentioned "old manifest" is directly retrieved from the k8s master itself and that Helm doesn't store any release related information in the aforementioned directories.

I'd greatly appreciate your help in clarifying this.

Thanks,
Abhirama.
Re: Helm 3 "state"? Is there such a thing

Fox, Kevin M <Kevin.Fox@...>
 

As far as I can tell, the "state" is made up of:
* caches
* credentials
* repos

So long as your stateless job (k8s pod) adds whatever credentials it needs and repo's as part of the job you should be fine loosing the state dirs when the pod is destroyed.

Thanks,
Kevin

________________________________________
From: cncf-helm@lists.cncf.io <cncf-helm@lists.cncf.io> on behalf of Abhirama <abhirama@gmail.com>
Sent: Tuesday, February 4, 2020 8:46 PM
To: cncf-helm@lists.cncf.io
Subject: [cncf-helm] Helm 3 "state"? Is there such a thing

Hi,

I'm sorry if the question comes across as too lame.

Now that Helm 3 is client-only, I understand that it stores "state" information along with the client in the directories determined by the environment variables XDG_CACHE_HOME, XDG_CONFIG_HOME and XDG_DATA_HOME. As a result, if Helm were to run on "stateless" machines (say if it were to run on a k8s pod every time it's run), does it still need access to the state it maintains in the aforementioned directories?

I've gone through https://helm.sh/docs/faq/#improved-upgrade-strategy-3-way-strategic-merge-patches<https://protect2.fireeye.com/v1/url?k=8fc82a5b-d37d15e2-8fc8004e-0cc47adc5fce-21e70389bd088c24&q=1&e=47578958-1bc5-4e52-8ace-0cf551c00ea5&u=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23improved-upgrade-strategy-3-way-strategic-merge-patches> and https://helm.sh/docs/faq/#xdg-base-directory-support<https://protect2.fireeye.com/v1/url?k=63b63cd0-3f030369-63b616c5-0cc47adc5fce-2e0c98b88fbbb452&q=1&e=47578958-1bc5-4e52-8ace-0cf551c00ea5&u=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23xdg-base-directory-support> and wasn't able to completely iron out my confusion. My guess is that, during the 3-way merge, the mentioned "old manifest" is directly retrieved from the k8s master itself and that Helm doesn't store any release related information in the aforementioned directories.

I'd greatly appreciate your help in clarifying this.

Thanks,
Abhirama.
Helm 3 "state"? Is there such a thing

Abhirama <abhirama@...>
 

Hi,

I'm sorry if the question comes across as too lame.

Now that Helm 3 is client-only, I understand that it stores "state" information along with the client in the directories determined by the environment variables  XDG_CACHE_HOME, XDG_CONFIG_HOME and XDG_DATA_HOME. As a result, if Helm were to run on "stateless" machines (say if it were to run on a k8s pod every time it's run), does it still need access to the state it maintains in the aforementioned directories?

I've gone through https://helm.sh/docs/faq/#improved-upgrade-strategy-3-way-strategic-merge-patches and https://helm.sh/docs/faq/#xdg-base-directory-support and wasn't able to completely iron out my confusion. My guess is that, during the 3-way merge, the mentioned "old manifest" is directly retrieved from the k8s master itself and that Helm doesn't store any release related information in the aforementioned directories.

I'd greatly appreciate your help in clarifying this.

Thanks,
Abhirama.
161 - 180 of 447