1. cncf-helm@lists.cncf.io
  2. Messages
   Date   
installing from source problem

Denis Chebotarev
 

Hi

I need to install Tiller locally for some reasons and the only way to do it is installing from source as I understand.

I followerd the steps listed in the docs here

There is a problem. Installation process hangs on on  "Fetching k8s.io/kubernetes" until I stop it manually. How to fix this problem?
Re: Take the Kubernetes Application Survey

Matt Farina
 

We're going to go around sharing it everywhere. I'll try to get to that later today.

Thanks for pointing it out.

On Thu, Apr 5, 2018 at 11:44 AM, Alexis Richardson <alexis@...> wrote:
Matt

Thank-you for doing this.  Please could you post on some of the CNCF
slack channels too?

alexis


On Thu, Apr 5, 2018 at 8:40 AM, Matt Farina <matt.farina@...> wrote:
> The survey is available at https://goo.gl/forms/ht61kKETiqVR103v1
>
> Backstory: For the past several months the App Def WG has been looking at
> how people build applications to run on Kubernetes and tools to work with
> them. In order to better understand end users a survey has been created to
> learn from a broader audience. The questions have been gathered from a
> variety of sources, including sub-project teams, and the resulting data will
> be shared with the community at large.
>
> If you build applications for Kubernetes or operates applications on
> Kubernetes we ask that you take a few minutes to let us know what you think.
>
> If you would, please share this survey with your networks so we can get
> input from a wide audience range.
>
> Thank you.
>
> --
> You received this message because you are subscribed to the Google Groups
> "kubernetes-sig-apps" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-sig-apps+unsubscribe@....
> To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2oYEfgWxt%3DHd7PQTE7TO%2BkSqWN-xc%2BzEjWxBBrm44drZg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Code Engineered - A blog on cloud, web, and software development.
Re: Take the Kubernetes Application Survey

Alexis Richardson <alexis@...>
 

Matt

Thank-you for doing this. Please could you post on some of the CNCF
slack channels too?

alexis

On Thu, Apr 5, 2018 at 8:40 AM, Matt Farina <matt.farina@gmail.com> wrote:
The survey is available at https://goo.gl/forms/ht61kKETiqVR103v1

Backstory: For the past several months the App Def WG has been looking at
how people build applications to run on Kubernetes and tools to work with
them. In order to better understand end users a survey has been created to
learn from a broader audience. The questions have been gathered from a
variety of sources, including sub-project teams, and the resulting data will
be shared with the community at large.

If you build applications for Kubernetes or operates applications on
Kubernetes we ask that you take a few minutes to let us know what you think.

If you would, please share this survey with your networks so we can get
input from a wide audience range.

Thank you.

--
You received this message because you are subscribed to the Google Groups
"kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to kubernetes-sig-apps+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2oYEfgWxt%3DHd7PQTE7TO%2BkSqWN-xc%2BzEjWxBBrm44drZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Take the Kubernetes Application Survey

Matt Farina
 

The survey is available at https://goo.gl/forms/ht61kKETiqVR103v1

Backstory: For the past several months the App Def WG has been looking at how people build applications to run on Kubernetes and tools to work with them. In order to better understand end users a survey has been created to learn from a broader audience. The questions have been gathered from a variety of sources, including sub-project teams, and the resulting data will be shared with the community at large.

If you build applications for Kubernetes or operates applications on Kubernetes we ask that you take a few minutes to let us know what you think.

If you would, please share this survey with your networks so we can get input from a wide audience range.

Thank you.
Re: Helm 3.0 Development Branch

Michelle Noorali
 

Sounds good to me!

Michelle Noorali

From: cncf-kubernetes-helm@... <cncf-kubernetes-helm@...> on behalf of Matt Butcher via Lists.Cncf.Io <matt.butcher=microsoft.com@...>
Sent: Thursday, March 29, 2018 1:09:57 PM
To: cncf-kubernetes-helm@...
Cc: cncf-kubernetes-helm@...
Subject: [cncf-kubernetes-helm] Helm 3.0 Development Branch
 
As we kick of Helm 3 development, we want to make sure that (a) it is easy to do work on the Helm 3 codebase, and (b) we don't break the Helm experience for existing users.

After doing some investigation, we discovered that many people clone the `master` branch and expect a working Helm 2 instance, so for development on helm 3, we propose initially doing the development work on a separate branch, and then merging that branch to master at `helm-3.0.0-beta.1` (a.k.a. The Distant Future).

So that leaves us with a name for the Helm 3 development branch. Our main two considerations for naming are (a) make it obvious, and (b) don't let it screw up SemVer-based clients like dep and glide.

We're proposing: `dev-v3` as the branch name.

How does that sound?
Re: Input requested: Helm v3 survey

Stefanie Arnold
 

Thanks Matt Farina!

For the how many users question, I think it depends what you want to know. Are you trying to get a sense of how many developers or operators are using helm? Or, is helm the go-to tool yet (versus kubectl)?

-Stef
 

>>> "Matt Fisher via Lists.Cncf.Io" <matt.fisher=microsoft.com@...> 03/29/18 3:30 PM >>>
This looks great!

Would it be useful to add an extra section under the "how many users are in your organization" question, asking:

Under your current job role, approximately how many users are using the stuff you built?
  • 1-10
  • 11-100
  • 101-1,000
  • 1,000+
  • unknown
This might be useful to inform us how high of an impact Helm has on the services they are operating, deploying or distributing. What do you think?


1504220459230_microsoft.png

Matthew Fisher, Caffeinated Software Engineer

Microsoft Azure Platform

Nanoose Bay, BC Canada

Email: matt.fisher@...

Phone: 1(250)937-1478

From: cncf-kubernetes-helm@... <cncf-kubernetes-helm@...> on behalf of Matt Farina <matt@...>
Sent: Thursday, March 29, 2018 2:06 PM
To: cncf-kubernetes-helm@...
Subject: [cncf-kubernetes-helm] Input requested: Helm v3 survey
 
To learn more about what people need out of helm v3 I'm starting to put together a survey. A document with questions is at the following link. If you have any feedback please feel open to adding it...

https://1drv.ms/w/s!At6-pjJ-bCdxgWcwG59q4YaEp9GC

Re: Input requested: Helm v3 survey

Matt Fisher <matt.fisher@...>
 

This looks great!

Would it be useful to add an extra section under the "how many users are in your organization" question, asking:

Under your current job role, approximately how many users are using the stuff you built?
  • 1-10
  • 11-100
  • 101-1,000
  • 1,000+
  • unknown
This might be useful to inform us how high of an impact Helm has on the services they are operating, deploying or distributing. What do you think?


1504220459230_microsoft.png

Matthew Fisher, Caffeinated Software Engineer

Microsoft Azure Platform

Nanoose Bay, BC Canada

Email: matt.fisher@...

Phone: 1(250)937-1478

From: cncf-kubernetes-helm@... <cncf-kubernetes-helm@...> on behalf of Matt Farina <matt@...>
Sent: Thursday, March 29, 2018 2:06 PM
To: cncf-kubernetes-helm@...
Subject: [cncf-kubernetes-helm] Input requested: Helm v3 survey
 
To learn more about what people need out of helm v3 I'm starting to put together a survey. A document with questions is at the following link. If you have any feedback please feel open to adding it...

https://1drv.ms/w/s!At6-pjJ-bCdxgWcwG59q4YaEp9GC

Input requested: Helm v3 survey

Matt Farina
 

To learn more about what people need out of helm v3 I'm starting to put together a survey. A document with questions is at the following link. If you have any feedback please feel open to adding it...

https://1drv.ms/w/s!At6-pjJ-bCdxgWcwG59q4YaEp9GC

Helm 3.0 Development Branch

Matt Butcher <matt.butcher@...>
 

As we kick of Helm 3 development, we want to make sure that (a) it is easy to do work on the Helm 3 codebase, and (b) we don't break the Helm experience for existing users.

After doing some investigation, we discovered that many people clone the `master` branch and expect a working Helm 2 instance, so for development on helm 3, we propose initially doing the development work on a separate branch, and then merging that branch to master at `helm-3.0.0-beta.1` (a.k.a. The Distant Future).

So that leaves us with a name for the Helm 3 development branch. Our main two considerations for naming are (a) make it obvious, and (b) don't let it screw up SemVer-based clients like dep and glide.

We're proposing: `dev-v3` as the branch name.

How does that sound?
Re: SPJ paper on Build Systems

Alexis Richardson <alexis@...>
 

Matt

Yes, absolutely build is a more complex case.  But it can be a super set of packaging, as exemplified by nix.

All these systems benefit from being deterministic and compositional, and I think the paper is useful for thinking about that.

Glad you liked!

A



On Tue, 20 Mar 2018, 14:17 Matt Farina, <matt.farina@...> wrote:
Alexis,

Thanks for sending that paper out. It was a fun read to start my day.

I think it's only tangentially relevant to Helm because Helm is a package manager rather than a build tool. A comparison that looked at tools like apt, yum, chocolatey, brew, and so forth would be a more relevant to Helm. Not to say there aren't concepts described in the paper that are important. I just want to make sure we're all on the same page for Helm's scope.

I got a real kick out of the way Excel is discussed in the build sense to highlight dynamic capabilities in a build system.

I was a little disappointed that container based systems, like drone and concourse, weren't brought up. The way container images are used to handle tasks is an interesting take.

For anyone interested in the benefits of bazel, especially on language tooling that doesn't have build caches the way Go does, this paper does have some nice insight.

Thanks again for sharing.


On Tue, Mar 20, 2018 at 5:36 AM, Alexis Richardson <alexis@...> wrote:
Hi

Dropping Computer Science, right about now...

Ilya dug up this new paper from Simon Peyton-Jones (MS Research) and
others.  They look at build systems from a theoretical POV.  Their
objective is relevant to Helm, although their notion of build is
richer.

"We have investigated multiple build systems, showing how their
properties are consequences of two implementation choices: what order
you build in and whether you decide to rebuild. By decomposing the
pieces, we show how to recompose the pieces to new points in the
design space. In particular, a simple recombination leads to a design
for a monadic cloud build system. Armed with that blueprint we hope to
actually implement such a system as future work."

This may also be relevant to wg-app-def folks.

alexis



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.
Re: SPJ paper on Build Systems

Matt Farina
 

Alexis,

Thanks for sending that paper out. It was a fun read to start my day.

I think it's only tangentially relevant to Helm because Helm is a package manager rather than a build tool. A comparison that looked at tools like apt, yum, chocolatey, brew, and so forth would be a more relevant to Helm. Not to say there aren't concepts described in the paper that are important. I just want to make sure we're all on the same page for Helm's scope.

I got a real kick out of the way Excel is discussed in the build sense to highlight dynamic capabilities in a build system.

I was a little disappointed that container based systems, like drone and concourse, weren't brought up. The way container images are used to handle tasks is an interesting take.

For anyone interested in the benefits of bazel, especially on language tooling that doesn't have build caches the way Go does, this paper does have some nice insight.

Thanks again for sharing.


On Tue, Mar 20, 2018 at 5:36 AM, Alexis Richardson <alexis@...> wrote:
Hi

Dropping Computer Science, right about now...

Ilya dug up this new paper from Simon Peyton-Jones (MS Research) and
others.  They look at build systems from a theoretical POV.  Their
objective is relevant to Helm, although their notion of build is
richer.

"We have investigated multiple build systems, showing how their
properties are consequences of two implementation choices: what order
you build in and whether you decide to rebuild. By decomposing the
pieces, we show how to recompose the pieces to new points in the
design space. In particular, a simple recombination leads to a design
for a monadic cloud build system. Armed with that blueprint we hope to
actually implement such a system as future work."

This may also be relevant to wg-app-def folks.

alexis



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.
SPJ paper on Build Systems

Alexis Richardson <alexis@...>
 

Hi

Dropping Computer Science, right about now...

Ilya dug up this new paper from Simon Peyton-Jones (MS Research) and
others. They look at build systems from a theoretical POV. Their
objective is relevant to Helm, although their notion of build is
richer.

"We have investigated multiple build systems, showing how their
properties are consequences of two implementation choices: what order
you build in and whether you decide to rebuild. By decomposing the
pieces, we show how to recompose the pieces to new points in the
design space. In particular, a simple recombination leads to a design
for a monadic cloud build system. Armed with that blueprint we hope to
actually implement such a system as future work."

This may also be relevant to wg-app-def folks.

alexis

PDF
build-systems.pdf

Re: Helm v3 User Stories

Quinton Hoole <quinton@...>
 



On Thu, Mar 15, 2018 at 10:28 AM, Matt Farina <matt.farina@...> wrote:
Quinton,


1. Your multi-cluster use cases would be interesting to kubernetes-SIG-multicluster, who might also be able to provide you with some valuable feedback, support tools, etc. Perhaps you would like to do a brief presentation/Q&A to sig-multicluster.  Their meetings are every second Tue at 09:30 Pacific.

 I'd be happy to come. Would the March 27th meeting be a good one for this?

Yup, March 27th works.  I've added you to the agenda..
 


2. Your roles document does not include a cluster admin role.  I would suggest explicitly mentioning this role, even if only to explicitly exclude it from your scope (with appropriate justification).  

Good idea. I'll craft a PR.

Cheers,
Matt


On Thu, Mar 15, 2018 at 1:09 PM, Quinton Hoole <quinton@...> wrote:
Hi Matt

Thanks, your writeups are very useful.  Two comments/questions:

1. Your multi-cluster use cases would be interesting to kubernetes-SIG-multicluster, who might also be able to provide you with some valuable feedback, support tools, etc. Perhaps you would like to do a brief presentation/Q&A to sig-multicluster.  Their meetings are every second Tue at 09:30 Pacific.
2. Your roles document does not include a cluster admin role.  I would suggest explicitly mentioning this role, even if only to explicitly exclude it from your scope (with appropriate justification).  

Q


On Thu, Mar 15, 2018 at 8:48 AM, Alexis Richardson <alexis@...> wrote:
+1, that is a major usage pattern for us and implemented using flux-helm.  

I don't think this has implications about what would trigger a pull/upgrade.  This is because anything that triggers a pull could be initiated by a push - eg CI writes a new build into the repos



On Thu, 15 Mar 2018, 15:42 Matt Farina, <matt.farina@...> wrote:
Brian, that's a good question.

These are definitely similar and may be able to be combined.

There have been requests to have a service running in a cluster that watches or is notified of changes in a chart. When a new version of a chart comes out the instance(s) in the cluster would be upgraded to the new version. Instead of CI pushing changes this is a pull method.

Similar flows are used by tools like Chef.

A similar flow could be built around kubectl.

Cheers,
Matt



On Wed, Mar 14, 2018 at 6:48 PM, Brian Grant <briangrant@...> wrote:
Very useful.

Questions about 1.1 and 1.8:

1.1: As an application operator, I want to be able to pull charts from within the cluster so that I can manage multiple clusters without exposing details to the CI system
1.8: In order to have a secure system as an application operator, I want a pull model so that I can manage multiple private clusters from one authoritative source

How are these 2 different? 1.1 is about pulling from cluster-local storage, whereas 1.8 is about pulling from a single source for all clusters?

1.8 is specifically about private clusters, or about the chart source being private? 

Pulling is in contrast to, say, a CI hook that invokes a client tool (e.g., kubectl apply) to push chart changes to a cluster or clusters? Does this have any implications about what would trigger a pull/upgrade?


On Wed, Mar 14, 2018 at 8:11 AM Matt Farina <matt.farina@...> wrote:
As part of the work to get going on Helm 3, the next major release, we've started to collect a set of user stories. The goal is to collect those that are above and beyond what's currently in Helm 2 rather than a complete set of all stories.

If you look at them you'll notice that they relate to the user profiles we previously created for Helm 3.

Please note, these are an initial set rather than a complete set of user stories.


--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe@....
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2ow1g3HVDuuGWdHiqJDTmoCW%3D6-V-Sxqs%3DBP2JSgFxgNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe@....
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2o_XOWLxJS8uYH7f9cnhXY_Zve0%3DOg5u69vRs-vw4SpBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsubscribe@....
To post to this group, send email to kubernetes-wg-contribex@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/CAOSi4U44YBxCV%3Dp4cQCfDbDYqLh_qjcJMqVWhU9F91cMNZEXNg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
Quinton Hoole
quinton@...



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.



--
Quinton Hoole
quinton@...
Re: Helm v3 User Stories

Quinton Hoole <quinton@...>
 

Hi Matt

Thanks, your writeups are very useful.  Two comments/questions:

1. Your multi-cluster use cases would be interesting to kubernetes-SIG-multicluster, who might also be able to provide you with some valuable feedback, support tools, etc. Perhaps you would like to do a brief presentation/Q&A to sig-multicluster.  Their meetings are every second Tue at 09:30 Pacific.
2. Your roles document does not include a cluster admin role.  I would suggest explicitly mentioning this role, even if only to explicitly exclude it from your scope (with appropriate justification).  

Q


On Thu, Mar 15, 2018 at 8:48 AM, Alexis Richardson <alexis@...> wrote:
+1, that is a major usage pattern for us and implemented using flux-helm.  

I don't think this has implications about what would trigger a pull/upgrade.  This is because anything that triggers a pull could be initiated by a push - eg CI writes a new build into the repos



On Thu, 15 Mar 2018, 15:42 Matt Farina, <matt.farina@...> wrote:
Brian, that's a good question.

These are definitely similar and may be able to be combined.

There have been requests to have a service running in a cluster that watches or is notified of changes in a chart. When a new version of a chart comes out the instance(s) in the cluster would be upgraded to the new version. Instead of CI pushing changes this is a pull method.

Similar flows are used by tools like Chef.

A similar flow could be built around kubectl.

Cheers,
Matt



On Wed, Mar 14, 2018 at 6:48 PM, Brian Grant <briangrant@...> wrote:
Very useful.

Questions about 1.1 and 1.8:

1.1: As an application operator, I want to be able to pull charts from within the cluster so that I can manage multiple clusters without exposing details to the CI system
1.8: In order to have a secure system as an application operator, I want a pull model so that I can manage multiple private clusters from one authoritative source

How are these 2 different? 1.1 is about pulling from cluster-local storage, whereas 1.8 is about pulling from a single source for all clusters?

1.8 is specifically about private clusters, or about the chart source being private? 

Pulling is in contrast to, say, a CI hook that invokes a client tool (e.g., kubectl apply) to push chart changes to a cluster or clusters? Does this have any implications about what would trigger a pull/upgrade?


On Wed, Mar 14, 2018 at 8:11 AM Matt Farina <matt.farina@...> wrote:
As part of the work to get going on Helm 3, the next major release, we've started to collect a set of user stories. The goal is to collect those that are above and beyond what's currently in Helm 2 rather than a complete set of all stories.

If you look at them you'll notice that they relate to the user profiles we previously created for Helm 3.

Please note, these are an initial set rather than a complete set of user stories.


--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe@....
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2ow1g3HVDuuGWdHiqJDTmoCW%3D6-V-Sxqs%3DBP2JSgFxgNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe@....
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2o_XOWLxJS8uYH7f9cnhXY_Zve0%3DOg5u69vRs-vw4SpBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsubscribe@....
To post to this group, send email to kubernetes-wg-contribex@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/CAOSi4U44YBxCV%3Dp4cQCfDbDYqLh_qjcJMqVWhU9F91cMNZEXNg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
Quinton Hoole
quinton@...
Re: Helm v3 User Stories

Matt Farina <matt.farina@...>
 

Quinton,


1. Your multi-cluster use cases would be interesting to kubernetes-SIG-multicluster, who might also be able to provide you with some valuable feedback, support tools, etc. Perhaps you would like to do a brief presentation/Q&A to sig-multicluster.  Their meetings are every second Tue at 09:30 Pacific.

 I'd be happy to come. Would the March 27th meeting be a good one for this?

2. Your roles document does not include a cluster admin role.  I would suggest explicitly mentioning this role, even if only to explicitly exclude it from your scope (with appropriate justification).  

Good idea. I'll craft a PR.

Cheers,
Matt


On Thu, Mar 15, 2018 at 1:09 PM, Quinton Hoole <quinton@...> wrote:
Hi Matt

Thanks, your writeups are very useful.  Two comments/questions:

1. Your multi-cluster use cases would be interesting to kubernetes-SIG-multicluster, who might also be able to provide you with some valuable feedback, support tools, etc. Perhaps you would like to do a brief presentation/Q&A to sig-multicluster.  Their meetings are every second Tue at 09:30 Pacific.
2. Your roles document does not include a cluster admin role.  I would suggest explicitly mentioning this role, even if only to explicitly exclude it from your scope (with appropriate justification).  

Q


On Thu, Mar 15, 2018 at 8:48 AM, Alexis Richardson <alexis@...> wrote:
+1, that is a major usage pattern for us and implemented using flux-helm.  

I don't think this has implications about what would trigger a pull/upgrade.  This is because anything that triggers a pull could be initiated by a push - eg CI writes a new build into the repos



On Thu, 15 Mar 2018, 15:42 Matt Farina, <matt.farina@...> wrote:
Brian, that's a good question.

These are definitely similar and may be able to be combined.

There have been requests to have a service running in a cluster that watches or is notified of changes in a chart. When a new version of a chart comes out the instance(s) in the cluster would be upgraded to the new version. Instead of CI pushing changes this is a pull method.

Similar flows are used by tools like Chef.

A similar flow could be built around kubectl.

Cheers,
Matt



On Wed, Mar 14, 2018 at 6:48 PM, Brian Grant <briangrant@...> wrote:
Very useful.

Questions about 1.1 and 1.8:

1.1: As an application operator, I want to be able to pull charts from within the cluster so that I can manage multiple clusters without exposing details to the CI system
1.8: In order to have a secure system as an application operator, I want a pull model so that I can manage multiple private clusters from one authoritative source

How are these 2 different? 1.1 is about pulling from cluster-local storage, whereas 1.8 is about pulling from a single source for all clusters?

1.8 is specifically about private clusters, or about the chart source being private? 

Pulling is in contrast to, say, a CI hook that invokes a client tool (e.g., kubectl apply) to push chart changes to a cluster or clusters? Does this have any implications about what would trigger a pull/upgrade?


On Wed, Mar 14, 2018 at 8:11 AM Matt Farina <matt.farina@...> wrote:
As part of the work to get going on Helm 3, the next major release, we've started to collect a set of user stories. The goal is to collect those that are above and beyond what's currently in Helm 2 rather than a complete set of all stories.

If you look at them you'll notice that they relate to the user profiles we previously created for Helm 3.

Please note, these are an initial set rather than a complete set of user stories.


--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe@....
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2ow1g3HVDuuGWdHiqJDTmoCW%3D6-V-Sxqs%3DBP2JSgFxgNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe@....
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2o_XOWLxJS8uYH7f9cnhXY_Zve0%3DOg5u69vRs-vw4SpBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsubscribe@....
To post to this group, send email to kubernetes-wg-contribex@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/CAOSi4U44YBxCV%3Dp4cQCfDbDYqLh_qjcJMqVWhU9F91cMNZEXNg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
Quinton Hoole
quinton@...



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.
Re: Helm v3 User Stories

Alexis Richardson <alexis@...>
 

+1, that is a major usage pattern for us and implemented using flux-helm.  

I don't think this has implications about what would trigger a pull/upgrade.  This is because anything that triggers a pull could be initiated by a push - eg CI writes a new build into the repos



On Thu, 15 Mar 2018, 15:42 Matt Farina, <matt.farina@...> wrote:
Brian, that's a good question.

These are definitely similar and may be able to be combined.

There have been requests to have a service running in a cluster that watches or is notified of changes in a chart. When a new version of a chart comes out the instance(s) in the cluster would be upgraded to the new version. Instead of CI pushing changes this is a pull method.

Similar flows are used by tools like Chef.

A similar flow could be built around kubectl.

Cheers,
Matt



On Wed, Mar 14, 2018 at 6:48 PM, Brian Grant <briangrant@...> wrote:
Very useful.

Questions about 1.1 and 1.8:

1.1: As an application operator, I want to be able to pull charts from within the cluster so that I can manage multiple clusters without exposing details to the CI system
1.8: In order to have a secure system as an application operator, I want a pull model so that I can manage multiple private clusters from one authoritative source

How are these 2 different? 1.1 is about pulling from cluster-local storage, whereas 1.8 is about pulling from a single source for all clusters?

1.8 is specifically about private clusters, or about the chart source being private? 

Pulling is in contrast to, say, a CI hook that invokes a client tool (e.g., kubectl apply) to push chart changes to a cluster or clusters? Does this have any implications about what would trigger a pull/upgrade?


On Wed, Mar 14, 2018 at 8:11 AM Matt Farina <matt.farina@...> wrote:
As part of the work to get going on Helm 3, the next major release, we've started to collect a set of user stories. The goal is to collect those that are above and beyond what's currently in Helm 2 rather than a complete set of all stories.

If you look at them you'll notice that they relate to the user profiles we previously created for Helm 3.

Please note, these are an initial set rather than a complete set of user stories.


--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe@....
To post to this group, send email to kubernetes-sig-apps@....
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2ow1g3HVDuuGWdHiqJDTmoCW%3D6-V-Sxqs%3DBP2JSgFxgNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe@....
To post to this group, send email to kubernetes-sig-apps@....
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2o_XOWLxJS8uYH7f9cnhXY_Zve0%3DOg5u69vRs-vw4SpBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Helm v3 User Stories

Matt Farina <matt.farina@...>
 

Brian, that's a good question.

These are definitely similar and may be able to be combined.

There have been requests to have a service running in a cluster that watches or is notified of changes in a chart. When a new version of a chart comes out the instance(s) in the cluster would be upgraded to the new version. Instead of CI pushing changes this is a pull method.

Similar flows are used by tools like Chef.

A similar flow could be built around kubectl.

Cheers,
Matt



On Wed, Mar 14, 2018 at 6:48 PM, Brian Grant <briangrant@...> wrote:
Very useful.

Questions about 1.1 and 1.8:

1.1: As an application operator, I want to be able to pull charts from within the cluster so that I can manage multiple clusters without exposing details to the CI system
1.8: In order to have a secure system as an application operator, I want a pull model so that I can manage multiple private clusters from one authoritative source

How are these 2 different? 1.1 is about pulling from cluster-local storage, whereas 1.8 is about pulling from a single source for all clusters?

1.8 is specifically about private clusters, or about the chart source being private? 

Pulling is in contrast to, say, a CI hook that invokes a client tool (e.g., kubectl apply) to push chart changes to a cluster or clusters? Does this have any implications about what would trigger a pull/upgrade?


On Wed, Mar 14, 2018 at 8:11 AM Matt Farina <matt.farina@...> wrote:
As part of the work to get going on Helm 3, the next major release, we've started to collect a set of user stories. The goal is to collect those that are above and beyond what's currently in Helm 2 rather than a complete set of all stories.

If you look at them you'll notice that they relate to the user profiles we previously created for Helm 3.

Please note, these are an initial set rather than a complete set of user stories.


--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe@....
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2ow1g3HVDuuGWdHiqJDTmoCW%3D6-V-Sxqs%3DBP2JSgFxgNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.
Re: Helm v3 User Stories

Brian Grant <briangrant@...>
 

Very useful.

Questions about 1.1 and 1.8:

1.1: As an application operator, I want to be able to pull charts from within the cluster so that I can manage multiple clusters without exposing details to the CI system
1.8: In order to have a secure system as an application operator, I want a pull model so that I can manage multiple private clusters from one authoritative source

How are these 2 different? 1.1 is about pulling from cluster-local storage, whereas 1.8 is about pulling from a single source for all clusters?

1.8 is specifically about private clusters, or about the chart source being private? 

Pulling is in contrast to, say, a CI hook that invokes a client tool (e.g., kubectl apply) to push chart changes to a cluster or clusters? Does this have any implications about what would trigger a pull/upgrade?


On Wed, Mar 14, 2018 at 8:11 AM Matt Farina <matt.farina@...> wrote:
As part of the work to get going on Helm 3, the next major release, we've started to collect a set of user stories. The goal is to collect those that are above and beyond what's currently in Helm 2 rather than a complete set of all stories.

If you look at them you'll notice that they relate to the user profiles we previously created for Helm 3.

Please note, these are an initial set rather than a complete set of user stories.


--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe@....
To post to this group, send email to kubernetes-sig-apps@....
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2ow1g3HVDuuGWdHiqJDTmoCW%3D6-V-Sxqs%3DBP2JSgFxgNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Helm stagnation or we're missing something?

Matt Farina
 

Dmitry,

I can add a little to what Adnan shared...

Helm tries to provide a semantic version guarantee to not break APIs on a major version. When the development from Helm v1 to Helm v2, which was mostly a re-write, there was a lot of development. After the 2.0.0 release there were new features until Helm v2 was in pretty good shape and Helm v2 was mostly seeing minor feature additions and bug fixes. Development slowed down naturally.

Open source projects, in general, go through different phases of activity. It can go up and down depending on what's going on. Helm had a peak during the Helm v2 major development and then it went into a valley. It's about to peak again at Helm v3 is being heavily invested in.

I can try to add some context to the issues brought up:

  • #3506 fixed a problem some of us needed to get fixed. There was a little pressure to get that fixed. Looking at the timing of the 3506, there was a 20 day gap between feedback and response to it. The alternative, that merged, was proposed and merged right about the same time that 3506 was responded to and made ready to go. I think it was more of a race condition to get one in. A change of a L or greater in size needs two helm core to approve and that happened on the alternative to 3506 first. I hope that helps understanding the why around them. There was definitely no ill will.
  • For #3481 the reason, I think, that bacongobbler tagged it was he supporting issue triaging. This is something core maintainers do. For me, I'm not sure how to quickly respond to it. I'd need to dig into the other work you linked off to as well as comparing what you want compared to the output with the `--debug` flag. Since I'm not working in that space I don't have the time to dig deeper and I'd hope for others to jump on this. A lack of response may mean others aren't working on the same problem space and otherwise busy. I know this can be frustrating. Have you reached out in slack or thought of coming to one of the helm developer calls to ask about it?
  • Helm tries to have good docs and examples so people can know how to use it. The Kubernetes community has talked about how insufficient docs is a problem for kubernetes as a whole. On #3540, I think it's reasonable to ask for those and then have a discussion. I would hope that when I made a new feature addition to helm 2 that someone would ask this of me. To hold me accountable.

This is all my 2 cents and an effort to add clarity. Contributions are appreciated and navigating the community interactions isn't always clean. Sorry for where it's messy.

Matt Farina
Helm v3 User Stories

Matt Farina <matt.farina@...>
 

As part of the work to get going on Helm 3, the next major release, we've started to collect a set of user stories. The goal is to collect those that are above and beyond what's currently in Helm 2 rather than a complete set of all stories.

If you look at them you'll notice that they relate to the user profiles we previously created for Helm 3.

Please note, these are an initial set rather than a complete set of user stories.
421 - 440 of 449