|
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. 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:
|
|
|
|
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.On Tue, Mar 6, 2018 at 12:10 PM, Brian Grant <briangrant@...> wrote:
--
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 ownSo, 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:
No disagreement regarding the different roles, but certain design affordances may be made if the deployment environment were known.
Yes, thanks.
|
|
|
|
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
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: -- 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
Hi, ## Prometheus server ConfigMap entries ## serverFiles: rules: ""
prometheus.yml: | global: scrape_interval: 1m BR,
Teja
|
|
|
|
Helm stagnation or we're missing something?
dmitry.shurupov@...
Dear community! With sincere hopes to find some ways to work with community efficiently and make Helm better,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? |
|
|
|
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:
--
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. |
|
|
|
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:
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 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:
|
|
|
|
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.On Wed, Mar 14, 2018 at 6:48 PM, Brian Grant <briangrant@...> wrote:
--
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.
toggle quoted message
Show quoted text
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:
|
|
|
|
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:
-- 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. --
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:
Yup, March 27th works. I've added you to the agenda..
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.On Tue, Mar 20, 2018 at 5:36 AM, Alexis Richardson <alexis@...> wrote: Hi --
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
toggle quoted message
Show quoted text
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:
|
|
|