cncf-helm@lists.cncf.io | Helm v3 User Stories

Home Messages Hashtags Subgroups

Date Date 1 - 7 of 7

Helm v3 User Stories

Matt Farina <matt.farina@...> #10 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.
More
Brian Grant <briangrant@...> #12 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.
More
Matt Farina <matt.farina@...> #13 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 toggle quoted message Show quoted text 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 mattfarina.com Go in Practice - A book of Recipes for the Go programming language. Engineered Web - A blog on cloud computing and web technologies.
More
Alexis Richardson <alexis@...> #14 +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 toggle quoted message Show quoted text 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 mattfarina.com 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.
More
Matt Farina <matt.farina@...> #15 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 mattfarina.com 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 mattfarina.com Go in Practice - A book of Recipes for the Go programming language. Engineered Web - A blog on cloud computing and web technologies.
More
Quinton Hoole <quinton@...> #16 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 toggle quoted message Show quoted text 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 mattfarina.com 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@...
More
Quinton Hoole <quinton@...> #17 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 mattfarina.com 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 mattfarina.com 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@...
More

1 - 7 of 7

1

Previous Topic Next Topic

Home Hashtags Subgroups Terms