Date   

Helm User Profiles

Matt Farina <matt.farina@...>
 

As we start development on Helm v3 we wanted to collect the user profiles to aid us in writing and evaluating user stories. User profiles are similar to personas but are categories rather than example people.

The first version of these is now available. There are names, brief descriptions, priority order (no two things can have the same priority), and some other details.

I'm sharing so that the audience interested in Helm is aware and for others working on other elements in Kubernetes can see what we're doing.

Cheers,
Matt Farina


Re: Helm User Profiles

Brian Grant <briangrant@...>
 

Very useful, thanks.

Question:

Are these categories intended to include or exclude someone creating their own bespoke application, which they build and deploy via CI/CD? The examples of WordPress and MySQL are suggestive of off-the-shelf applications, whose developers may not care whether they run on Kubernetes at all, while engineers at Reddit and Ubisoft (to pick 2 users from Helm summit) probably care where their applications run.

On Tue, Mar 6, 2018 at 7:58 AM, Matt Farina <matt.farina@...> wrote:
As we start development on Helm v3 we wanted to collect the user profiles to aid us in writing and evaluating user stories. User profiles are similar to personas but are categories rather than example people.

The first version of these is now available. There are names, brief descriptions, priority order (no two things can have the same priority), and some other details.

I'm sharing so that the audience interested in Helm is aware and for others working on other elements in Kubernetes can see what we're doing.

Cheers,
Matt Farina

--
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/CAMPAG2p1poJ-0wuwxYOhatmhCQTw5EGTNf%3DuBJns9iaBpPBjsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Helm User Profiles

Matt Farina <matt.farina@...>
 

These categories are intended to include those creating their own bespoke applications.

The role, which is described in a user profile, for someone developing the bespoke application is separate from the role of someone operating the application. In some organizations the same physical person will perform both roles and it other organizations they will be different sets of people.

The user profiles are targeted at Helm, which is a package manager, rather than the general case of application development and operation. I would expect related tools to have a similar but different set of user profiles shaped around what they're working on.

Does that help?


On Tue, Mar 6, 2018 at 12:10 PM, Brian Grant <briangrant@...> wrote:
Very useful, thanks.

Question:

Are these categories intended to include or exclude someone creating their own bespoke application, which they build and deploy via CI/CD? The examples of WordPress and MySQL are suggestive of off-the-shelf applications, whose developers may not care whether they run on Kubernetes at all, while engineers at Reddit and Ubisoft (to pick 2 users from Helm summit) probably care where their applications run.

On Tue, Mar 6, 2018 at 7:58 AM, Matt Farina <matt.farina@...> wrote:
As we start development on Helm v3 we wanted to collect the user profiles to aid us in writing and evaluating user stories. User profiles are similar to personas but are categories rather than example people.

The first version of these is now available. There are names, brief descriptions, priority order (no two things can have the same priority), and some other details.

I'm sharing so that the audience interested in Helm is aware and for others working on other elements in Kubernetes can see what we're doing.

Cheers,
Matt Farina

--
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/CAMPAG2p1poJ-0wuwxYOhatmhCQTw5EGTNf%3DuBJns9iaBpPBjsw%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 User Profiles

Josh Berkus <jberkus@...>
 

On 03/06/2018 10:52 AM, Matt Farina wrote:
These categories are intended to /include/ those creating their own
bespoke applications.

The role, which is described in a user profile, for someone developing
the bespoke application is separate from the role of someone operating
the application. In some organizations the same physical person will
perform both roles and it other organizations they will be different
sets of people.
So, I've come across a use-case for Helm at several different user
sites, enough that it seems to constitute a major use-case: using Helm
as a minority component of a larger build pipeline.

I can't see how this use-case fits into any of the roles you've already
defined; those roles all seem to have hands-on use of helm in mind.
Which role would this fit into? I guess I'm looking for something like
"build system architect/maintainer".


--
--
Josh Berkus
Kubernetes Community
Red Hat OSAS


Re: Helm User Profiles

Brian Grant <briangrant@...>
 

On Tue, Mar 6, 2018 at 10:52 AM, Matt Farina <matt.farina@...> wrote:
These categories are intended to include those creating their own bespoke applications.

The role, which is described in a user profile, for someone developing the bespoke application is separate from the role of someone operating the application. In some organizations the same physical person will perform both roles and it other organizations they will be different sets of people.

No disagreement regarding the different roles, but certain design affordances may be made if the deployment environment were known.
 

The user profiles are targeted at Helm, which is a package manager, rather than the general case of application development and operation. I would expect related tools to have a similar but different set of user profiles shaped around what they're working on.

Does that help?

Yes, thanks.
 


On Tue, Mar 6, 2018 at 12:10 PM, Brian Grant <briangrant@...> wrote:
Very useful, thanks.

Question:

Are these categories intended to include or exclude someone creating their own bespoke application, which they build and deploy via CI/CD? The examples of WordPress and MySQL are suggestive of off-the-shelf applications, whose developers may not care whether they run on Kubernetes at all, while engineers at Reddit and Ubisoft (to pick 2 users from Helm summit) probably care where their applications run.

On Tue, Mar 6, 2018 at 7:58 AM, Matt Farina <matt.farina@...> wrote:
As we start development on Helm v3 we wanted to collect the user profiles to aid us in writing and evaluating user stories. User profiles are similar to personas but are categories rather than example people.

The first version of these is now available. There are names, brief descriptions, priority order (no two things can have the same priority), and some other details.

I'm sharing so that the audience interested in Helm is aware and for others working on other elements in Kubernetes can see what we're doing.

Cheers,
Matt Farina

--
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/CAMPAG2p1poJ-0wuwxYOhatmhCQTw5EGTNf%3DuBJns9iaBpPBjsw%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 User Profiles

Matt Farina <matt.farina@...>
 

Josh,

I might be able to share how this fits...

So, I've come across a use-case for Helm at several different user
sites, enough that it seems to constitute a major use-case:  using Helm
as a minority component of a larger build pipeline. 
 
I can't see how this use-case fits into any of the roles you've already
defined; those roles all seem to have hands-on use of helm in mind.
Which role would this fit into?  I guess I'm looking for something like
"build system architect/maintainer". 

What is the build system person doing? Distributing application? Operating applications?

I'll try to illustrate with some examples.

Bitnami maintains some of the community charts. In doing so they have automation that picks up changes to apps and creates different build artifacts. One of those is a PR to the community chart for the changes. There's helm as a minority component in a larger system and it uses automation. The user profile this would fit under is the application distributor.

Another example could be the CI toolchain for the community charts repository. All changes to charts go through a series of analysis, including both static and runtime checks, and helm is one of many tools. It's used within scripts. Again, the user here is that of an application distributor because that's where the community charts fall.

A third example would be someone running a custom application for their company. The CI situation could be similar to that of the community charts but there are also steps to deploy to production. Here we have the role of application operator.

A "build system architect/maintainer" is a real person who is performing some roles described in the user profiles. The "build system architect/maintainer" may do different things depending on the organization they are in or the end goal of that system. Mapping these to the varying ways we work in companies is hard. Breaking them down into composable building blocks is easier.

Does that help?

Cheers,
Matt


On Tue, Mar 6, 2018 at 2:00 PM, Josh Berkus <jberkus@...> wrote:
On 03/06/2018 10:52 AM, Matt Farina wrote:
> These categories are intended to /include/ those creating their own
> bespoke applications.
>
> The role, which is described in a user profile, for someone developing
> the bespoke application is separate from the role of someone operating
> the application. In some organizations the same physical person will
> perform both roles and it other organizations they will be different
> sets of people.

So, I've come across a use-case for Helm at several different user
sites, enough that it seems to constitute a major use-case:  using Helm
as a minority component of a larger build pipeline.

I can't see how this use-case fits into any of the roles you've already
defined; those roles all seem to have hands-on use of helm in mind.
Which role would this fit into?  I guess I'm looking for something like
"build system architect/maintainer".


--
--
Josh Berkus
Kubernetes Community
Red Hat OSAS



--
Matt Farina

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

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


Configuration files Handling

@Tejaswini_Vadlamudi
 

Hi,

We are using Helm in our staging systems. Have a question to you guys on helm install command.

Recently we started using Prometheus a CNCF product.

The Prometheus server need a Configuration file, this file is deployed as a ConfigMap. But the file content is stored in values.yaml

During our automation, if we want to change a value of a file it is really problematic to change at helm CLI. We should update the values.yaml file itself to a new one.

While we automate, it would be good if we can use something like:

helm install --name monitoring --set server.prometheus.yml.global.scrape_interval=1 prometheus

Here is the content of yaml file:

## Prometheus server ConfigMap entries

##

serverFiles:

  rules: ""

 

  prometheus.yml: |

    global:

      scrape_interval: 1m

Just curious if Helm has plan to handle these kind of things.

BR,
Teja

 


Helm stagnation or we're missing something?

dmitry.shurupov@...
 

Dear community!

Helm is crucial in our software stack since we heavily use it in our own CI/CD workflow tool (sorry, we still have no English docs but we'll be improving that soon). It's so important that missing some features means real problems in some parts of our business. Luckily, Helm is Open Source, so we are happy to become a part of its community and share our improvements… however, that's where our issue appears. Almost all our attempts to bring some singificant (for us) updates end up not being really accepted.

Here are examples describing our general feeling:
1. https://github.com/kubernetes/helm/issues/3481 ­— that's our biggest disappointment as we've been doing a lot for logging, however there's no reaction since the very beginning of this issue. Does nobody need it? We are open to hear it — everything can be better than being totally uncertain.
2. https://github.com/kubernetes/helm/pull/3506 — this PR has appeared after we've seen not so successfull attempt to add "wait" feature to "helm init": that previous (not our) PR was accepted but didn't work actually and brought new problems to the code. So, we've decided to clean the code and fix this "wait". It seems developers (not so fast but anyway…) have liked our idea, however they have decided to rewrite everything by themselves. We could have done it also if they just asked us for that… Okay, so here are developers ready to spend their time for this minor thing. What about our next PR?
3. https://github.com/kubernetes/helm/pull/3540 — in this PR, we are requested to make docs + tutorial/example + tests while we haven't seen such requirements for other similar things (already existing policies). It's not we don't want to do it — it's just unexpected to observe this attitude here while minor issues are being rewritten by few developers. Is it only minor changes which are currently welcome in Helm?

If we add some public stats (https://github.com/kubernetes/helm/graphs/contributors) and check an overall scope of last PRs being merged (https://github.com/kubernetes/helm/pulls?q=is%3Apr+is%3Aclosed), it just strengthens our belief Helm is stagnating — at least, in public and especially, in contrast to Kubernetes itself. At the same time, it's the official package manager for K8s what makes us really care (and the whole community we hope?). We need some new features*, we are happy to implement them but we are blocked by core developers community of the project to pull (and, sometimes, even discuss) our changes. There can be another guess: some developers are actively working on a big new release of Helm with no real public signs of that (if so, it's not an Open Source way for sure).

Can anybody please shed us some light on what's really happening with Helm and what are the plans for its future? Maybe, all our "feeling" is totally irrelevant and we're doing something wrong?

* At least, we know one more important problem in Helm: isn't it strange to have a package manager which can't really check that the package has been installed successfully?


With sincere hopes to find some ways to work with community efficiently and make Helm better,

--
Dmitry Shurupov,
JSC "Flant"
http://flant.ru/
+7 (495) 721-10-27, add. 442


Re: Helm stagnation or we're missing something?

Adnan Abdulhussein
 

Hi Dmitry,

Thanks for reaching out. I can't speak for those issues and PRs in particular, but I wanted to make you aware that the Helm community is currently undergoing planning for Helm 3, and as such there are no major features being planned for Helm 2 releases.

Quite a few things are (possibly) set to change in Helm 3. For example, the server-side component (Tiller) is intended to be removed and possibly replaced by a Kubernetes controller. Release state will be stored as CRD objects.

Also, there are some new ideas around how hooks will work in Helm 3. Sounds like you're using hooks quite a bit, so it would be good to have you collaborate on the proposal to make sure what we do there will make sense in your workflow.

It's still early days in the planning, but if you'd like to get involved I encourage you to join the Thursday developer calls (https://github.com/kubernetes-helm/community/blob/master/communication.md#weekly-meeting).


On Wed, Mar 14, 2018 at 9:41 AM Dmitry Shurupov <dmitry.shurupov@...> wrote:
Dear community!

Helm is crucial in our software stack since we heavily use it in our own CI/CD workflow tool (sorry, we still have no English docs but we'll be improving that soon). It's so important that missing some features means real problems in some parts of our business. Luckily, Helm is Open Source, so we are happy to become a part of its community and share our improvements… however, that's where our issue appears. Almost all our attempts to bring some singificant (for us) updates end up not being really accepted.

Here are examples describing our general feeling:
1. https://github.com/kubernetes/helm/issues/3481 ­— that's our biggest disappointment as we've been doing a lot for logging, however there's no reaction since the very beginning of this issue. Does nobody need it? We are open to hear it — everything can be better than being totally uncertain.
2. https://github.com/kubernetes/helm/pull/3506 — this PR has appeared after we've seen not so successfull attempt to add "wait" feature to "helm init": that previous (not our) PR was accepted but didn't work actually and brought new problems to the code. So, we've decided to clean the code and fix this "wait". It seems developers (not so fast but anyway…) have liked our idea, however they have decided to rewrite everything by themselves. We could have done it also if they just asked us for that… Okay, so here are developers ready to spend their time for this minor thing. What about our next PR?
3. https://github.com/kubernetes/helm/pull/3540 — in this PR, we are requested to make docs + tutorial/example + tests while we haven't seen such requirements for other similar things (already existing policies). It's not we don't want to do it — it's just unexpected to observe this attitude here while minor issues are being rewritten by few developers. Is it only minor changes which are currently welcome in Helm?

If we add some public stats (https://github.com/kubernetes/helm/graphs/contributors) and check an overall scope of last PRs being merged (https://github.com/kubernetes/helm/pulls?q=is%3Apr+is%3Aclosed), it just strengthens our belief Helm is stagnating — at least, in public and especially, in contrast to Kubernetes itself. At the same time, it's the official package manager for K8s what makes us really care (and the whole community we hope?). We need some new features*, we are happy to implement them but we are blocked by core developers community of the project to pull (and, sometimes, even discuss) our changes. There can be another guess: some developers are actively working on a big new release of Helm with no real public signs of that (if so, it's not an Open Source way for sure).

Can anybody please shed us some light on what's really happening with Helm and what are the plans for its future? Maybe, all our "feeling" is totally irrelevant and we're doing something wrong?

* At least, we know one more important problem in Helm: isn't it strange to have a package manager which can't really check that the package has been installed successfully?


With sincere hopes to find some ways to work with community efficiently and make Helm better,

--
Dmitry Shurupov,

--
Adnan Abdulhussein
Software Engineer, Bitnami
+1 866 870 2383
@prydonius

Confidential - All Rights Reserved.
Bitnami (c) 2018


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.



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


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 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

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@...>
 

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

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

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@...


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


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.


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.

1 - 20 of 454