Date
1 - 7 of 7
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.
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:
--Please note, these are an initial set rather than a complete set of user stories.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.
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 <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:
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 sourceHow 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:--Please note, these are an initial set rather than a complete set of user stories.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.
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.
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:
MattCheers,A similar flow could be built around kubectl.Similar flows are used by tools like Chef.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.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: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 sourceHow 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:--Please note, these are an initial set rather than a complete set of user stories.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.
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 FarinaGo 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.
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 MattThanks, 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).QOn Thu, Mar 15, 2018 at 8:48 AM, Alexis Richardson <alexis@...> wrote:You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.+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:To view this discussion on the web visit https://groups.google.com/d/msMattCheers,A similar flow could be built around kubectl.Similar flows are used by tools like Chef.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.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: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 sourceHow 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:--Please note, these are an initial set rather than a complete set of user stories.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.
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/CAMPAG 2ow1g3HVDuuGWdHiqJDTmoCW%3D6- V-Sxqs%3DBP2JSgFxgNA%40mail. gmail.com.
For more options, visit https://groups.google.com/d/optout.
----Matt FarinaGo 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. gid/kubernetes-sig-apps/CAMPAG 2o_XOWLxJS8uYH7f9cnhXY_Zve0% 3DOg5u69vRs-vw4SpBA%40mail. gmail.com.
For more options, visit https://groups.google.com/d/optout.
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/CA OSi4U44YBxCV%3Dp4cQCfDbDYqLh_q jcJMqVWhU9F91cMNZEXNg%40mail.g mail.com. --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@...>
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:To view this discussion on the web visit https://groups.google.com/d/MattCheers,A similar flow could be built around kubectl.Similar flows are used by tools like Chef.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.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: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 sourceHow 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:--Please note, these are an initial set rather than a complete set of user stories.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.
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 FarinaGo 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. 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.
--
Quinton Hoole
quinton@...
quinton@...
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,MattOn Thu, Mar 15, 2018 at 1:09 PM, Quinton Hoole <quinton@...> wrote:Hi MattThanks, 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).QOn Thu, Mar 15, 2018 at 8:48 AM, Alexis Richardson <alexis@...> wrote:You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.+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:To view this discussion on the web visit https://groups.google.com/d/msMattCheers,A similar flow could be built around kubectl.Similar flows are used by tools like Chef.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.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: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 sourceHow 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:--Please note, these are an initial set rather than a complete set of user stories.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.
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/CAMPAG 2ow1g3HVDuuGWdHiqJDTmoCW%3D6-V -Sxqs%3DBP2JSgFxgNA%40mail.gma il.com.
For more options, visit https://groups.google.com/d/optout.
----Matt FarinaGo 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. gid/kubernetes-sig-apps/CAMPAG 2o_XOWLxJS8uYH7f9cnhXY_Zve0%3D Og5u69vRs-vw4SpBA%40mail.gmail .com.
For more options, visit https://groups.google.com/d/optout.
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/CA OSi4U44YBxCV%3Dp4cQCfDbDYqLh_q jcJMqVWhU9F91cMNZEXNg%40mail.g mail.com. --Quinton Hoole
quinton@...
--Matt FarinaGo in Practice - A book of Recipes for the Go programming language.Engineered Web - A blog on cloud computing and web technologies.
Quinton Hoole
quinton@...
quinton@...