Date   

Helm Hub move to Artifact Hub

Matt Farina
 

The Helm Hub has made it far easier to find charts that are distributed around the Internet. General purpose search engines don't make it easy and the Helm Hub, being Kubernetes and charts specific, provided an improvement.

The Helm Hub is built on Monocular which was originally designed for purposes other than running a large many repo site. It has worked well but its limitations have started to showcase themselves. For example, the repository listing on the charts search page does not visually scale well and the pageload times increase with each new chart added to the site. We knew that some changes needed to happen for the Helm Hub to scale better.

The Artifact Hub is a Kubernetes artifact search site. It handles Helm charts and other cloud native artifacts. This site is self service for both publishers and consumers and designed to scale. The Artifact Hub was recently accepted as a CNCF Sandbox project and was born out of work in the CNCF.

Instead of investing in Helm Hub software that does a better job scaling, we are going to migrate over to use the Artifact Hub. This means the Helm Hub site will eventually redirect to the Artifact Hub and the Helm Hub codebase will be archived.

The issue tracking this migration is at https://github.com/helm/hub/issues/439

Some steps in the migration have already begun. This includes making all of the existing Helm Hub repositories available in the Artifact Hub. Those that were not already listed on the Artifact Hub were migrated. If you own one of the repositories that has been migrated and would like to take over management please file an issue on the Helm Hub and we can transfer the ownership.

We are happy to answer any questions related to this.


Feedback on proposal

jorgecarleitao@...
 

Hi,

I am writing to formalize a proposal to extend Helm 3 in a backward compatible manner to allow passing derived values to subcharts without exposing them in `values.yaml`. I wrote this an issue on github, 8576, and opened a PR with a minimal implementation the proposal, 8580. I consider this a major feature, and as such I am opening this topic here to gather your thoughts.

I am willing to drive this, but I will need some guidance.

Best,
Jorge


Re: stepping down

Martin Hickey
 

Hi Michelle,
 
It was great to have had a chance to work with you. All the best in your new adventures.

Regards,
Martin
 
 

----- Original message -----
From: "minooral via lists.cncf.io" <minooral=microsoft.com@...>
Sent by: cncf-helm@...
To: cncf-helm@...
Cc:
Subject: [EXTERNAL] [cncf-helm] stepping down
Date: Wed, Jul 8, 2020 12:35 AM
 

[Edited Message Follows]

Hey Helmettes,

It's been a pleasure being a core maintainer on the Helm project since it's initial release Helm Classic (v1) in 2015 and probably the coolest experience of my career. I am officially stepping down as core maintainer to focus on other responsibilities. I've learned a lot from everyone involved and appreciate having had the opportunity to work with you all.
https://github.com/helm/helm/pull/8414

--- Feel free to ignore the rest of this if you don't care for long messages but I do want to take a few minutes to give my thanks.---

Thank you Matt Butcher for giving me room and guidance to build out parts of Helm v1 and v2. I learned a lot about how to do open source and build a community, how to research and think through design decisions and iterate on them, and how to write Go from you. I will always appreciate your patience and the opportunities you encouraged me to take. I remember you asking me to compile my code on the spot and and show Bitnami (and others) what we were working on in the early days. Obviously, I don't recommend that for everyone but when you asked me do that (more than once), it helped me learn how to talk about what we were working on on the spot. I learned how to demo, give the right amount of context without prep, and it made me more confident about showing work in progress. Thanks for helping build a safe and respectful environment to work in (you and Adam both). Thank you Adam Reese for being my partner in crime, for always supporting me and having my back. I loved going through this journey with you from building a PaaS at Engine Yard to building a package manager for Kubernetes. I will never forget the times where we'd get on calls and admit to each other we were both totally lost lol. I learned a lot about how to ask the right questions and articulate problems more clearly from you. Thank you Brian Hardock for helping me think deeper about the software and tools we use. Adnan, Miguel, Sameer, Jack Francis, Brian Grant, Vic, Sebastian, Bridget, Matt Fisher, Martin. I've had a blast with you all. I know I am missing people (sorry). Super proud of this tool and community and still humbled I got the opportunity to work on it.


Cheers,

Michelle Noorali
 


stepping down

minooral@...
 
Edited

Hey Helmettes,

It's been a pleasure being a core maintainer on the Helm project since it's initial release Helm Classic (v1) in 2015 and probably the coolest experience of my career. I am officially stepping down as core maintainer to focus on other responsibilities. I've learned a lot from everyone involved and appreciate having had the opportunity to work with you all.
https://github.com/helm/helm/pull/8414

--- Feel free to ignore the rest of this if you don't care for long messages but I do want to take a few minutes to give my thanks.---

Thank you Matt Butcher for giving me room and guidance to build out parts of Helm v1 and v2. I learned a lot about how to do open source and build a community, how to research and think through design decisions and iterate on them, and how to write Go from you. I will always appreciate your patience and the opportunities you encouraged me to take. I remember you asking me to compile my code on the spot and and show Bitnami (and others) what we were working on in the early days. Obviously, I don't recommend that for everyone but when you asked me do that (more than once), it helped me learn how to talk about what we were working on on the spot. I learned how to demo, give the right amount of context without prep, and it made me more confident about showing work in progress. Thanks for helping build a safe and respectful environment to work in (you and Adam both). Thank you Adam Reese for being my partner in crime, for always supporting me and having my back. I loved going through this journey with you from building a PaaS at Engine Yard to building a package manager for Kubernetes. I will never forget the times where we'd get on calls and admit to each other we were both totally lost lol. I learned a lot about how to ask the right questions and articulate problems more clearly from you. Thank you Brian Hardock for helping me think deeper about the software and tools we use. Adnan, Miguel, Sameer, Jack Francis, Brian Grant, Vic, Sebastian, Bridget, Matt Fisher, Martin. I've had a blast with you all. I know I am missing people (sorry). Super proud of this tool and community and still humbled I got the opportunity to work on it.


Cheers,

Michelle Noorali


Re: How can we achieve automatic rollback in case of "helm upgrade" failures?

Matt Fisher <matt.fisher@...>
 

Not sure where you got the information that the atomic flag doesn’t exist in Helm 3. I just checked, and it’s been there since Helm 3.0.0, and it’s present in HEAD.



If you want to automatically roll back in case of a failure, you can use the atomic flag. I’m not aware of another feature to handle rollbacks.

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada



From: cncf-helm@... <cncf-helm@...> on behalf of vtejaswini1 via lists.cncf.io <vtejaswini1=gmail.com@...>
Sent: Wednesday, July 1, 2020 10:00 AM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] How can we achieve automatic rollback in case of "helm upgrade" failures?
 
Hi,

Does anyone have ideas about supporting automatic rollback in terms of failures? Over slack, people recommend different sets of tools. What is the recommended approach or best feasible approach to use?

Do I need to use any helm operator or?

I also notice helm3 not supporting the atomic flag, which was created to support automatic rollback.

Thanks,
Teja


How can we achieve automatic rollback in case of "helm upgrade" failures?

@Tejaswini_Vadlamudi
 

Hi,

Does anyone have ideas about supporting automatic rollback in terms of failures? Over slack, people recommend different sets of tools. What is the recommended approach or best feasible approach to use?

Do I need to use any helm operator or?

I also notice helm3 not supporting the atomic flag, which was created to support automatic rollback.

Thanks,
Teja


Re: What is the proper way to rollback using helm, Is it using "helm rollback" or "helm upgrade olderversion"?

Paul Czarkowski <pczarkowski@...>
 

Hi Teja!

Both are completely valid option.  People generally like the rollback commands as it's rolling your kubernetes manifests back to a known good version, therefore if there was an error introduced by a change in the Helm charts themselves it would not continue that error.

However this option doesn't take into account the application itself. If there is a bug in the application or you have a backwards incompatible database schema change, then it would make sense to roll forward with a newer image and a `helm upgrade`.



From: cncf-helm@... <cncf-helm@...> on behalf of vtejaswini1@... <vtejaswini1@...>
Sent: Wednesday, July 1, 2020 8:35 AM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] What is the proper way to rollback using helm, Is it using "helm rollback" or "helm upgrade olderversion"?
 
Hi,

I was looking at downgrading software on failure. I wonder if I need to run upgrade an older version or use the "helm rollback" command.

Well, I don't have enough arguments about why I need to use "helm rollback" for rolling back software.

Does anyone know the reasons behind this support?

Thanks,
Teja


What is the proper way to rollback using helm, Is it using "helm rollback" or "helm upgrade olderversion"?

@Tejaswini_Vadlamudi
 

Hi,

I was looking at downgrading software on failure. I wonder if I need to run upgrade an older version or use the "helm rollback" command.

Well, I don't have enough arguments about why I need to use "helm rollback" for rolling back software.

Does anyone know the reasons behind this support?

Thanks,
Teja


Re: Helm for Microservices Deployments

Lei Zhang
 

Hi Berin

The answer should also depend on what's your intention to group these pieces together.

If the intention is to packaging and distributing, Paul's suggestion of two-layer charts should work. Another similar approach could be CNAB (https://cnab.io/) + charts, so CNAB could be used as the parent layer of your package. 

If the intention is to create a application definition for Kubernetes so you can declare dependencies of the components etc, then server side app model may be the solution, for example:  https://speakerdeck.com/resouer/oam-as-kubernetes-application-definition. In this case, you will have a helm chart to package a single app-config.yaml


Re: Helm for Microservices Deployments

Loritsch, Berin <bloritsch@...>
 

Out of curiosity, why wouldn't you simply have a master helm chart for the full application that declares all of the dependencies? As opposed to learning yet another tool (https://github.com/roboll/helmfile).


On Fri, Jun 26, 2020 at 2:53 PM Loritsch, Berin via lists.cncf.io <bloritsch=novetta.com@...> wrote:
The complication I have is that the customer I have has very outdated concepts for approving and managing deployments.  As a result, our devops pipeline is segregated from the production environment.  However as part of the delivery we can provide the containers and helm charts for all the pieces.  Once we get the go-ahead from the approval body we can run the "helm install" or "helm upgrade" process for the whole app.

It is our full intention to have sub-charts at least for each microservice should this archaic business process be brought into the 21st century.  However, in the interim we will need a master chart to define the entire application.  I did find a good approach for using labels to address some parts ot the problem: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

Thanks for the pointer to helmfile.  I will look at that to see if I can use it to manage our deployments.  We manage our dev and QA instances of the application using full DevOps.  The disconnect comes in when we have to manage an acceptance test and production instance of the application on our customer's private cloud.  Each of those environments requires some customization so we can point at managed resources without risking production problems.


On Fri, Jun 26, 2020 at 11:49 AM Paul Czarkowski <pczarkowski@...> wrote:
In my opinion at least, Ideally each microservice would have its own fully independent chart, and be deployed and managed independely by some sort of CI/CD solution that roughly resembles gitops.

If you need to share data or values between microservices, then you could look to using a library chart ( https://helm.sh/docs/topics/library_charts/ ) which you could use to define extra labels to help tie environments together (via metadata at least) and do things like set names for service discovery, create secrets with TLS certs, that kind of thing.

If you need to deploy all of the microservices as a bundle, then I would would reach up a layer to a tool like helmfile (https://github.com/roboll/helmfile) which can help you deploy and manage sets of loosely coupled helm charts.

From: cncf-helm@... <cncf-helm@...> on behalf of Loritsch, Berin <bloritsch@...>
Sent: Thursday, June 25, 2020 3:21 PM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] Helm for Microservices Deployments
 
As I dive deeper into the world of Kubernetes so that I understand what I need my charts to do, and how I intend to design the templates for my environment, I am curious how Helm ties things together.

For example, we have 30+ microservices in 7 functional areas, all for one application.  We want to handle deployments with horizontal scaling, volumes, etc.

I think the picture is crystal clear when we are talking about one service.  I.e. 1 microservice would have 1 deployment, 1 hpa, ingress instructions, a service definition, and volumes and configmaps to support it.  I look at some of the examples for larger systems, and the examples I see use labels to tie things together.

When I create a parent chart that declares all of the microservices as dependencies, does Helm inject labels on my behalf?  For example, given I am in a namespace for the environment, I want to type "helm install wicketz example/wicketzapp" and then later when I need to update it or uninstall it, I would update the "wicketz" app in that custom namespace.  Additionally, as we replace microservices we no longer need because they are now redundant with Kubernetes features, I'd like the update to remove the deployments that are no longer needed.

What's the glue that binds things together?  Is that something I have to manage myself, or be aware of as I'm writing my helm charts?  Unfortunately, too many of the examples I find are too simplistic to answer the questions I'm having now.

--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708



--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708



--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708


Re: Helm for Microservices Deployments

Loritsch, Berin <bloritsch@...>
 

The complication I have is that the customer I have has very outdated concepts for approving and managing deployments.  As a result, our devops pipeline is segregated from the production environment.  However as part of the delivery we can provide the containers and helm charts for all the pieces.  Once we get the go-ahead from the approval body we can run the "helm install" or "helm upgrade" process for the whole app.

It is our full intention to have sub-charts at least for each microservice should this archaic business process be brought into the 21st century.  However, in the interim we will need a master chart to define the entire application.  I did find a good approach for using labels to address some parts ot the problem: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

Thanks for the pointer to helmfile.  I will look at that to see if I can use it to manage our deployments.  We manage our dev and QA instances of the application using full DevOps.  The disconnect comes in when we have to manage an acceptance test and production instance of the application on our customer's private cloud.  Each of those environments requires some customization so we can point at managed resources without risking production problems.


On Fri, Jun 26, 2020 at 11:49 AM Paul Czarkowski <pczarkowski@...> wrote:
In my opinion at least, Ideally each microservice would have its own fully independent chart, and be deployed and managed independely by some sort of CI/CD solution that roughly resembles gitops.

If you need to share data or values between microservices, then you could look to using a library chart ( https://helm.sh/docs/topics/library_charts/ ) which you could use to define extra labels to help tie environments together (via metadata at least) and do things like set names for service discovery, create secrets with TLS certs, that kind of thing.

If you need to deploy all of the microservices as a bundle, then I would would reach up a layer to a tool like helmfile (https://github.com/roboll/helmfile) which can help you deploy and manage sets of loosely coupled helm charts.

From: cncf-helm@... <cncf-helm@...> on behalf of Loritsch, Berin <bloritsch@...>
Sent: Thursday, June 25, 2020 3:21 PM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] Helm for Microservices Deployments
 
As I dive deeper into the world of Kubernetes so that I understand what I need my charts to do, and how I intend to design the templates for my environment, I am curious how Helm ties things together.

For example, we have 30+ microservices in 7 functional areas, all for one application.  We want to handle deployments with horizontal scaling, volumes, etc.

I think the picture is crystal clear when we are talking about one service.  I.e. 1 microservice would have 1 deployment, 1 hpa, ingress instructions, a service definition, and volumes and configmaps to support it.  I look at some of the examples for larger systems, and the examples I see use labels to tie things together.

When I create a parent chart that declares all of the microservices as dependencies, does Helm inject labels on my behalf?  For example, given I am in a namespace for the environment, I want to type "helm install wicketz example/wicketzapp" and then later when I need to update it or uninstall it, I would update the "wicketz" app in that custom namespace.  Additionally, as we replace microservices we no longer need because they are now redundant with Kubernetes features, I'd like the update to remove the deployments that are no longer needed.

What's the glue that binds things together?  Is that something I have to manage myself, or be aware of as I'm writing my helm charts?  Unfortunately, too many of the examples I find are too simplistic to answer the questions I'm having now.

--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708



--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708


Re: Helm for Microservices Deployments

Paul Czarkowski <pczarkowski@...>
 

In my opinion at least, Ideally each microservice would have its own fully independent chart, and be deployed and managed independely by some sort of CI/CD solution that roughly resembles gitops.

If you need to share data or values between microservices, then you could look to using a library chart ( https://helm.sh/docs/topics/library_charts/ ) which you could use to define extra labels to help tie environments together (via metadata at least) and do things like set names for service discovery, create secrets with TLS certs, that kind of thing.

If you need to deploy all of the microservices as a bundle, then I would would reach up a layer to a tool like helmfile (https://github.com/roboll/helmfile) which can help you deploy and manage sets of loosely coupled helm charts.


From: cncf-helm@... <cncf-helm@...> on behalf of Loritsch, Berin <bloritsch@...>
Sent: Thursday, June 25, 2020 3:21 PM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] Helm for Microservices Deployments
 
As I dive deeper into the world of Kubernetes so that I understand what I need my charts to do, and how I intend to design the templates for my environment, I am curious how Helm ties things together.

For example, we have 30+ microservices in 7 functional areas, all for one application.  We want to handle deployments with horizontal scaling, volumes, etc.

I think the picture is crystal clear when we are talking about one service.  I.e. 1 microservice would have 1 deployment, 1 hpa, ingress instructions, a service definition, and volumes and configmaps to support it.  I look at some of the examples for larger systems, and the examples I see use labels to tie things together.

When I create a parent chart that declares all of the microservices as dependencies, does Helm inject labels on my behalf?  For example, given I am in a namespace for the environment, I want to type "helm install wicketz example/wicketzapp" and then later when I need to update it or uninstall it, I would update the "wicketz" app in that custom namespace.  Additionally, as we replace microservices we no longer need because they are now redundant with Kubernetes features, I'd like the update to remove the deployments that are no longer needed.

What's the glue that binds things together?  Is that something I have to manage myself, or be aware of as I'm writing my helm charts?  Unfortunately, too many of the examples I find are too simplistic to answer the questions I'm having now.

--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708


Re: Announcing ChartCenter, the free central repository for Helm charts

Jimmy Zelinskie <jimmyzelinskie@...>
 

Congratulations on the launch, Rimas!


On Fri, Jun 26, 2020 at 9:49 AM Rimas <rmocius@...> wrote:

Helm charts make your Kubernetes deployments as easy as possible and today I’m happy to announce: ChartCenter, the free central repository for Helm charts.

 chartcenter.io is an immutable, safe, and free central repository that includes high-level vulnerability scanning, robust metadata, dependency graphs and more! Use our superior search to uncover a list of matches based on name, description, and keywords. You can also add your own charts and repositories.

You can use it as a single helm repo to access many charts from different helm repos.

Take a look to my blog for more details https://rimusz.net/chartcenter 2


Announcing ChartCenter, the free central repository for Helm charts

Rimas
 

Helm charts make your Kubernetes deployments as easy as possible and today I’m happy to announce: ChartCenter, the free central repository for Helm charts.

 chartcenter.io is an immutable, safe, and free central repository that includes high-level vulnerability scanning, robust metadata, dependency graphs and more! Use our superior search to uncover a list of matches based on name, description, and keywords. You can also add your own charts and repositories.

You can use it as a single helm repo to access many charts from different helm repos.

Take a look to my blog for more details https://rimusz.net/chartcenter 2


Helm for Microservices Deployments

Loritsch, Berin <bloritsch@...>
 

As I dive deeper into the world of Kubernetes so that I understand what I need my charts to do, and how I intend to design the templates for my environment, I am curious how Helm ties things together.

For example, we have 30+ microservices in 7 functional areas, all for one application.  We want to handle deployments with horizontal scaling, volumes, etc.

I think the picture is crystal clear when we are talking about one service.  I.e. 1 microservice would have 1 deployment, 1 hpa, ingress instructions, a service definition, and volumes and configmaps to support it.  I look at some of the examples for larger systems, and the examples I see use labels to tie things together.

When I create a parent chart that declares all of the microservices as dependencies, does Helm inject labels on my behalf?  For example, given I am in a namespace for the environment, I want to type "helm install wicketz example/wicketzapp" and then later when I need to update it or uninstall it, I would update the "wicketz" app in that custom namespace.  Additionally, as we replace microservices we no longer need because they are now redundant with Kubernetes features, I'd like the update to remove the deployments that are no longer needed.

What's the glue that binds things together?  Is that something I have to manage myself, or be aware of as I'm writing my helm charts?  Unfortunately, too many of the examples I find are too simplistic to answer the questions I'm having now.

--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708


Helm using the same template for python and java springboot

kumaryoa@...
 

Hi,

I would like to know can we use the same helm chart template for python and java sprinboot applications. I have my git repository name(sample) is common for these both the codes. But it uses different memory configs and envrionment variables. Please suggest me how can i deploy both the code using single helm chart template.


Re: Share common configmap / data

Paul Czarkowski <pczarkowski@...>
 

Hey,

Helm Charts themselves can't access contents of a configmap.  You could either set these values as `global` values and make them available across all charts (if using chart dependencies/child charts - https://helm.sh/docs/chart_template_guide/subcharts_and_globals/ )  or you can create the configmap and then if the other charts mount that configmap as env vars or a file and load them in to each deployment that way.

On Sat, May 9, 2020 at 11:51 AM <frnd4u.ashok@...> wrote:
I'm newbie to helm and trying to understand and develop helm charts for my organization, so pardon my knowledge on the subject.This is my idea of sharing a common library configmap to access across multiple charts.
I want to identify account number and other details of AWS deployment, so I can set some values accordingly.
Is this correct? I can pass in .Values.account appropriate value and how do I go about accessing in this example account_number
apiVersion: v1
kind: ConfigMap
metadata:
name: aws
data:
account_number:
{{- if eq .Values.account "dev" }}
{{- printf "YX3XX2YX1YX6"}}
{{- else if eq .Values.account "stg" }}
{{- printf "X48XY438611X"}}
{{- else if eq .Values.account "prd" }}
{{- printf "Y83Y23X888X1"}}
{{- end }}


Re: local filesystem chart dependencies

Paul Czarkowski <pczarkowski@...>
 

Hi Marvin,

I believe the dependency entry should as follows ( `..` instead of `.` since the game-tracker chart is in the same parent directory as `teamdb-ui`:

```
dependencies:
  - name: game-tracker
    version: 0.1.0
    repository: "file://../game-tracker"
```

On Mon, May 11, 2020 at 5:36 AM Just Marvin <marvin.the.cynical.robot@...> wrote:
Hi,

    I've got two charts on my filesystem - which are not uploaded yet to any repo. They are both located in the same directory.

[zaphod@oc3027208274 helm]$ ls
game-tracker  teamdb-ui


Snippet from Charts.yaml of "teamdb-ui":

dependencies:
  - name: game-tracker
    version: 0.1.0
    repository: "file://./game-tracker"


    However, when I do a "dependency list", I get this status:

zaphod@oc3027208274 helm]$ helm dependency list teamdb-ui
NAME         VERSION REPOSITORY           STATUS
game-tracker 0.1.0   file://./game-tracker missing

    I have tried various syntaxes - file://. and other variants as well. Its also not clear if the dependency needs to be to the chart version or the app version, but I have tried with both. How do I get this working?

Regards,
Marvin


local filesystem chart dependencies

Just Marvin
 

Hi,

    I've got two charts on my filesystem - which are not uploaded yet to any repo. They are both located in the same directory.

[zaphod@oc3027208274 helm]$ ls
game-tracker  teamdb-ui


Snippet from Charts.yaml of "teamdb-ui":

dependencies:
  - name: game-tracker
    version: 0.1.0
    repository: "file://./game-tracker"


    However, when I do a "dependency list", I get this status:

zaphod@oc3027208274 helm]$ helm dependency list teamdb-ui
NAME         VERSION REPOSITORY           STATUS
game-tracker 0.1.0   file://./game-tracker missing

    I have tried various syntaxes - file://. and other variants as well. Its also not clear if the dependency needs to be to the chart version or the app version, but I have tried with both. How do I get this working?

Regards,
Marvin


Share common configmap / data

frnd4u.ashok@...
 

I'm newbie to helm and trying to understand and develop helm charts for my organization, so pardon my knowledge on the subject.This is my idea of sharing a common library configmap to access across multiple charts.
I want to identify account number and other details of AWS deployment, so I can set some values accordingly.
Is this correct? I can pass in .Values.account appropriate value and how do I go about accessing in this example account_number
apiVersion: v1
kind: ConfigMap
metadata:
name: aws
data:
account_number:
{{- if eq .Values.account "dev" }}
{{- printf "YX3XX2YX1YX6"}}
{{- else if eq .Values.account "stg" }}
{{- printf "X48XY438611X"}}
{{- else if eq .Values.account "prd" }}
{{- printf "Y83Y23X888X1"}}
{{- end }}

121 - 140 of 449