--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cluster...@googlegroups.com.
To post to this group, send email to kubernetes-sig-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/5C0A2F30-5480-4C7B-AC60-BA5768C4DF48%40vmware.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cluster...@googlegroups.com.
To post to this group, send email to kubernetes-sig-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/8ca618fd-3413-4a5b-8e2b-acd4cee3416a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAHJadQ%2B0eXL49TZjS-cqfqyJo2UqdTYrEQPGmY1ELAu6Cca5fg%40mail.gmail.com.
(+ SIG Docs, since they're our trusted wordsmiths and SIG Arch, as they may have opinions)Thanks so much for raising this, Andrew! Could we also open an issue to track?I feel like in the places where "master" is not referenced, "control plane" is, and it's generally (maybe my assumption here) understood to be the set of nodes which hold the control plane components, namely, api-server, scheduler, and controller-manager.Could we not opt to simply continue referencing it as such and search/replace "master", where appropriate?Another suggestion (combined with your's) would be:- Plural: control plane pool- Singular: control plane nodeWe have the concept of node/agent pools, so this feels "natural" to extend that to control plane naming."Controller" feels weird, because I feel it would cause confusion between a controller (machine) and the currently accepted controller (reconciliation loop for some Kubernetes resource).As for naming of the first control plane node to come up, "primary" may cause confusion, as it implies that the first control plane node to be instantiated is also the going to be the one always doing the work, which isn't necessarily true in HA scenarios."Initial" control plane node sounds more "correct" for that.If we're going for shorter, I like "control node" as well.-- Stephen
--To post to this group, send email to kubernetes-sig-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/A395BCB3-7BF1-4D50-8DCD-6FBF8D3964F1%40vmware.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAFQm5yTpdDCZS5WoabGM9rX_vHdFZoYmaKkpNLHpZUvASR-a0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/4854B942-DA89-482D-8D68-894D1AB5D8B0%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAB_J3bYRN6bzMra6dTj7bAA6MZFVgVjLx%2Behw2BZXGeZd3irQA%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "kubernetes-sig-docs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-docs/OF287988F3.9C95EF37-ON852583FE.00120993-852583FE.00129DC6%40notes.na.collabserv.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAFto3a2We4G060SavB4Zh1Xc-MKOux24rJSyDsFLUdh97XLxog%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAKCBhs5vG%3D-sxqzXbkrWr0pxgejOe3po6teHUDqSK%2B9%3DG5_wAg%40mail.gmail.com.
Late to the chat, but I think we're circling on a topic that comes up about once a year. It's not just the words we use but they expectations they imply.Calling a machine (virt or phys) a "Master" implies that machines are set aside for this purpose. while this is often true, it's not necessarily so.Calling a machine a "master node" or a "control plane node" sort of implies that the machine is simultaneously a master and a node, though it seems very split on whether tools set things up this way.We have "node-role.kubernetes.io/master" as a label on nodes, which is used by a handful of things to switch their behaviors (e.g. should a node be considered available for external LB bounces).Some environments register dedicated control-plane machines as Nodes in the controlled cluster, some do not.Some environments run the control plane (or parts of it) on non-dedicated nodes in the controlled cluster.Some environments the control plane as jobs in a different cluster.This is a mess.I am all for finding better words, but I think that is a second-order concern. I'd really like us to find some consistency in how we explain and think about these various operating modes. Can we reduce the space? Can we get more principled?E.g. I would love some rules along the lines of, and as crisp as:* Control plane components can be run on dedicated or non-dedicated machines.* If a machine is registered as a Node in kubernetes, it is subject to "usual" kubernetes semantics - e.g. scheduling, daemonsets, load-balancers, etc.* If you do not want "usual" kubernetes semantics on a machine, do not register it as a Node
* Whether a node is currently running components of the control plane is not semantically meaningful
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAO_RewYtRRmB_NyZ50rhPGpMCK%2B6rywcJjpdXqw_Da-x_QVjEw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAMrP4D0%3Ddb4-%2BcZNm%3Dw03H98Era80v0_QdAzkrv8pDSZrnzR5A%40mail.gmail.com.
Late to the chat, but I think we're circling on a topic that comes up about once a year. It's not just the words we use but they expectations they imply.Calling a machine (virt or phys) a "Master" implies that machines are set aside for this purpose. while this is often true, it's not necessarily so.Calling a machine a "master node" or a "control plane node" sort of implies that the machine is simultaneously a master and a node, though it seems very split on whether tools set things up this way.We have "node-role.kubernetes.io/master" as a label on nodes, which is used by a handful of things to switch their behaviors (e.g. should a node be considered available for external LB bounces)
Some environments register dedicated control-plane machines as Nodes in the controlled cluster, some do not.Some environments run the control plane (or parts of it) on non-dedicated nodes in the controlled cluster.Some environments the control plane as jobs in a different cluster.This is a mess.I am all for finding better words, but I think that is a second-order concern. I'd really like us to find some consistency in how we explain and think about these various operating modes. Can we reduce the space? Can we get more principled?E.g. I would love some rules along the lines of, and as crisp as:* Control plane components can be run on dedicated or non-dedicated machines.* If a machine is registered as a Node in kubernetes, it is subject to "usual" kubernetes semantics - e.g. scheduling, daemonsets, load-balancers, etc.* If you do not want "usual" kubernetes semantics on a machine, do not register it as a Node* Whether a node is currently running components of the control plane is not semantically meaningful* Specific Kubernetes semantics (e.g. scheduling, daemonsets, load-balancers, etc.) should be governed by specific and orthogonal controls (e.g. labels, annotations, fields)
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAO_RewYtRRmB_NyZ50rhPGpMCK%2B6rywcJjpdXqw_Da-x_QVjEw%40mail.gmail.com.
On Tue, May 28, 2019 at 8:46 AM Tim Hockin <tho...@google.com> wrote:Late to the chat, but I think we're circling on a topic that comes up about once a year. It's not just the words we use but they expectations they imply.Calling a machine (virt or phys) a "Master" implies that machines are set aside for this purpose. while this is often true, it's not necessarily so.Calling a machine a "master node" or a "control plane node" sort of implies that the machine is simultaneously a master and a node, though it seems very split on whether tools set things up this way.We have "node-role.kubernetes.io/master" as a label on nodes, which is used by a handful of things to switch their behaviors (e.g. should a node be considered available for external LB bounces).Some environments register dedicated control-plane machines as Nodes in the controlled cluster, some do not.Some environments run the control plane (or parts of it) on non-dedicated nodes in the controlled cluster.Some environments the control plane as jobs in a different cluster.This is a mess.I am all for finding better words, but I think that is a second-order concern. I'd really like us to find some consistency in how we explain and think about these various operating modes. Can we reduce the space? Can we get more principled?E.g. I would love some rules along the lines of, and as crisp as:* Control plane components can be run on dedicated or non-dedicated machines.* If a machine is registered as a Node in kubernetes, it is subject to "usual" kubernetes semantics - e.g. scheduling, daemonsets, load-balancers, etc.* If you do not want "usual" kubernetes semantics on a machine, do not register it as a NodeOr taint it etc. (Do we need an admission controller that e.g. does an RBAC check before permitting someone to make a pod with a given toleration?)
* Whether a node is currently running components of the control plane is not semantically meaningfulIt is in terms of how severe a container escape is, which is why I maintain that the relevant concept is that of a security domain.
On May 28, 2019, at 11:46 AM, 'Tim Hockin' via kubernetes-sig-architecture <kubernetes-si...@googlegroups.com> wrote:Late to the chat, but I think we're circling on a topic that comes up about once a year. It's not just the words we use but they expectations they imply.Calling a machine (virt or phys) a "Master" implies that machines are set aside for this purpose. while this is often true, it's not necessarily so.Calling a machine a "master node" or a "control plane node" sort of implies that the machine is simultaneously a master and a node, though it seems very split on whether tools set things up this way.We have "node-role.kubernetes.io/master" as a label on nodes, which is used by a handful of things to switch their behaviors (e.g. should a node be considered available for external LB bounces)Some environments register dedicated control-plane machines as Nodes in the controlled cluster, some do not.Some environments run the control plane (or parts of it) on non-dedicated nodes in the controlled cluster.Some environments the control plane as jobs in a different cluster.This is a mess.I am all for finding better words, but I think that is a second-order concern. I'd really like us to find some consistency in how we explain and think about these various operating modes. Can we reduce the space? Can we get more principled?E.g. I would love some rules along the lines of, and as crisp as:* Control plane components can be run on dedicated or non-dedicated machines.* If a machine is registered as a Node in kubernetes, it is subject to "usual" kubernetes semantics - e.g. scheduling, daemonsets, load-balancers, etc.* If you do not want "usual" kubernetes semantics on a machine, do not register it as a Node* Whether a node is currently running components of the control plane is not semantically meaningful* Specific Kubernetes semantics (e.g. scheduling, daemonsets, load-balancers, etc.) should be governed by specific and orthogonal controls (e.g. labels, annotations, fields)Yes, we should enforce this strongly going forward and start cleaning up the mistakes (Jordan has caught a couple before they could land, but it’s commonly confusing to new contributors)LBs should be keying off a taint or a scoped label (“lb.service.k8s.io/exclude-from-endpoints”), not coupled to role.
I don’t want us to continue coupling “type of node” across multiple concepts (lb, scheduling, volumes) either, and we need to be strict about letting it continue.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAO_RewY-rGpF-V2GgiVT0XOZ3qzi76%2Bh6TcEtBgeo8pJz%2BgMgw%40mail.gmail.com.
Hi Stephen,
I definitely am. We are a year past when I posted the original message - https://groups.google.com/d/msg/kubernetes-sig-cluster-lifecycle/IjN_9n0KEUg/h4i93a_EAgAJ. It seems like this is one of those topics that results in violent agreement – we all know we need to do *something*, but because no one can agree on what, nothing changes. I would love to finally see some movement on this.
--
-a
Andrew Kutz
Engineer, VMware
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAFQm5yRHtq9pmzZ%3DQds6QiP1jCwApEhpR35tv4Nz0ko66eVPrw%40mail.gmail.com.
I would like to join the WG if possible to help in the work
On Wed, Jun 10, 2020 at 1:14 AM Stephen Augustus <Stephen@agst.us> wrote:
It's been on my mind and this feels like a good time to pick this discussion back up.A few people have reached out to me and I've seen some awesome PRs[1] and issues[2] come through discussing using more inclusive language across the board.So...
- Who's interested in working together on this?
- What do we think are some good next steps?
To echo Vallery's previous email, maybe this actually does merit a Working Group, given we've had some stops and starts in the conversation?-- Stephen
On Wed, May 29, 2019 at 6:09 AM David Emory Watson <davidewatson@gmail.com> wrote:
Maybe we should drop the term node when referring to Clusters/ControlPlanes… It will match CAPI, and address the user concerns.David.
On Tue, May 28, 2019 at 10:57 AM David Emory Watson <davidewatson@gmail.com> wrote:
I get it. I don't think the majority of people think in those terms...Your axioms would be good documentation.David.
On Tue, May 28, 2019 at 10:29 AM 'Tim Hockin' via kubernetes-sig-architecture <kubernetes-sig-architecture@googlegroups.com> wrote:
512-658-8368
On 5/16/19, 7:40 PM, "shidaqiu2018" <shidaqiu2018@gmail.com> wrote:
+1
Sounds good!
But pilot is a concept in istio.
Doesn't that cause confusion?
------------------ Original ------------------
From: Daniel Lipovetsky <daniel@platform9.com>
Date: 周五,5月 17,2019 03:53
To: Michael Taufen <mtaufen@google.com>
Cc: Fabrizio Pandini <fabrizio.pandini@gmail.com>, kubernetes-sig-cluster-lifecycle <kubernetes-sig-cluster-lifecycle@googlegroups.com>
Subject: Re: The way we discuss control plane members
Typically, apiserver/scheduler/controller-manager are deployed one a single node if they are deployed as static pods. Otherwise, an existing scheduler distributes them across an existing cluster.
I do like "control node" for its simplicity. But, when I think of "node," I think of a kubelet on a machine. And sometimes the above components run in another Kubernetes cluster, so "node" might be misleading.
I kind of like "control replica," but it's a mouthful, as is "control node." If we're going to throw out "master," why not considering throwing out "control plane" as well? Is there a more concise alternative?
What does Kubernetes translate to?
Pilot, or shipmaster <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fclassic.studylight.org%2Flex%2Fgrk%2Fview.cgi%3Fnumber%3D2942&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128203992&sdata=dvgtEvyFGE%2FsNORgfJDCa9WxvIrZxbtV99770sLis%2Fw%3D&reserved=0>. So if 'master is short for the latter, and we don't like it, how about pilot?
Daniel
On Thu, May 16, 2019 at 10:49 AM 'Michael Taufen' via kubernetes-sig-cluster-lifecycle <kubernetes-sig-cluster-lifecycle@googlegroups.com> wrote:
+1
Maybe "control node?"
Thinking in terms of control-plane and data-plane is more accurate anyway, "master" is ambiguous and also a misnomer as it suggests the control plane components must run on the same machine.
Whatever we pick it should be short and easy to say, and make sense the first time you hear it. I think this is half the reason people still use "master."
From: Fabrizio Pandini
<fabrizio.pandini@gmail.com>
Date: Wed, May 15, 2019 at 11:04 PM
To: kubernetes-sig-cluster-lifecycle
+1
Fyi during HA work we are trying to use consistently control-plane node ("bootstrap control-plane node" and "secondary control-plane nodes" or "joining control-plane node" when referring to the init/join workflow).
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/8ca618fd-3413-4a5b-8e2b-acd4cee3416a%40googlegroups.com <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fkubernetes-sig-cluster-lifecycle%2F8ca618fd-3413-4a5b-8e2b-acd4cee3416a%2540googlegroups.com&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128213986&sdata=5KG6%2BO%2FgK3%2BIEqPGA4o99SpB6SH1YVS5ZgSMi%2BSULEc%3D&reserved=0>.
For more options, visit
https://groups.google.com/d/optout <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128213986&sdata=6SGT5YRIxsC4NYhhu4Tnqw9sxOklivcKG5JDFfcw56E%3D&reserved=0>.
--
Michael Taufen
Google SWE
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAHJadQ%2B0eXL49TZjS-cqfqyJo2UqdTYrEQPGmY1ELAu6Cca5fg%40mail.gmail.com <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fkubernetes-sig-cluster-lifecycle%2FCAHJadQ%252B0eXL49TZjS-cqfqyJo2UqdTYrEQPGmY1ELAu6Cca5fg%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128223977&sdata=s%2FzAnywWJJwQMu3PkCX7JcGOgqb2FCWgMytX3W148ng%3D&reserved=0>.
For more options, visit
https://groups.google.com/d/optout <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128223977&sdata=dyEXWr5gdX9J%2Bh32PcMMdM9qnz2STzX0k0f43zwMeJ0%3D&reserved=0>.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAMAYzbCj5E%3D%3D0k-bEC2ogC8v1yW_H%3DfuGtKe6ar703cFi9Kz4Q%40mail.gmail.com <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fkubernetes-sig-cluster-lifecycle%2FCAMAYzbCj5E%253D%253D0k-bEC2ogC8v1yW_H%253DfuGtKe6ar703cFi9Kz4Q%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128233971&sdata=wq5z%2BB1IN8BjMvqCNfE1yN4AxfbS5ea%2BIoynFx7T%2BtY%3D&reserved=0>.
For more options, visit
https://groups.google.com/d/optout <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128233971&sdata=sdyZD8KXtDJDeljqpEBAf67%2B6CnaAiUlx80y3ccgKRM%3D&reserved=0>.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/tencent_3C79EBA6D9A20BA243FAAD09%40qq.com <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fkubernetes-sig-cluster-lifecycle%2Ftencent_3C79EBA6D9A20BA243FAAD09%2540qq.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128243966&sdata=d9zADyznsSAWJml60zPyLN7hFEilNpLZxj2%2BfzMeS9A%3D&reserved=0>.
For more options, visit
https://groups.google.com/d/optout <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128243966&sdata=JfWAHBRtlUsR%2FrHRRaLLeQqJj1Baml26vB2TpDaqRtQ%3D&reserved=0>.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cluster-lifecycle+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-sig-cluster-lifecycle@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/A395BCB3-7BF1-4D50-8DCD-6FBF8D3964F1%40vmware.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAFQm5yTpdDCZS5WoabGM9rX_vHdFZoYmaKkpNLHpZUvASR-a0g%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-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/4854B942-DA89-482D-8D68-894D1AB5D8B0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAB_J3bYRN6bzMra6dTj7bAA6MZFVgVjLx%2Behw2BZXGeZd3irQA%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-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAFto3a2We4G060SavB4Zh1Xc-MKOux24rJSyDsFLUdh97XLxog%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-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAKCBhs5vG%3D-sxqzXbkrWr0pxgejOe3po6teHUDqSK%2B9%3DG5_wAg%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-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAO_RewYtRRmB_NyZ50rhPGpMCK%2B6rywcJjpdXqw_Da-x_QVjEw%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-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAO_RewY-rGpF-V2GgiVT0XOZ3qzi76%2Bh6TcEtBgeo8pJz%2BgMgw%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-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cluster-lifecycle+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAFQm5yRHtq9pmzZ%3DQds6QiP1jCwApEhpR35tv4Nz0ko66eVPrw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cluster-lifecycle+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAOxYG4w40bPLBdfv8sVMEsBLYV%2BK86253ayTKBHFGpA5BKznhA%40mail.gmail.com.
Ditto! Count me in. I'd love to help on this front.Sincerely,
Taylor Dolezal
On Wed, Jun 10, 2020 at 7:44 AM, Carlos Tadeu Panato Jr <cta...@gmail.com> wrote:
I would like to join the WG if possible to help in the work
On Wed, Jun 10, 2020 at 1:14 AM Stephen Augustus <Ste...@agst.us> wrote:
It's been on my mind and this feels like a good time to pick this discussion back up.A few people have reached out to me and I've seen some awesome PRs[1] and issues[2] come through discussing using more inclusive language across the board.So...
- Who's interested in working together on this?
- What do we think are some good next steps?
To echo Vallery's previous email, maybe this actually does merit a Working Group, given we've had some stops and starts in the conversation?-- Stephen
On Wed, May 29, 2019 at 6:09 AM David Emory Watson <davide...@gmail.com> wrote:
Maybe we should drop the term node when referring to Clusters/ControlPlanes… It will match CAPI, and address the user concerns.David.
On Tue, May 28, 2019 at 10:57 AM David Emory Watson <davide...@gmail.com> wrote:
I get it. I don't think the majority of people think in those terms...Your axioms would be good documentation.David.
On Tue, May 28, 2019 at 10:29 AM 'Tim Hockin' via kubernetes-sig-architecture <kubernetes-si...@googlegroups.com> wrote:
512-658-8368
On 5/16/19, 7:40 PM, "shidaqiu2018" <shidaq...@gmail.com> wrote:
+1
Sounds good!
But pilot is a concept in istio.
Doesn't that cause confusion?
------------------ Original ------------------
From: Daniel Lipovetsky <dan...@platform9.com>
Date: 周五,5月 17,2019 03:53
To: Michael Taufen <mta...@google.com>
Cc: Fabrizio Pandini <fabrizi...@gmail.com>, kubernetes-sig-cluster-lifecycle <kubernetes-sig-cluster-life...@googlegroups.com>
Subject: Re: The way we discuss control plane members
Typically, apiserver/scheduler/controller-manager are deployed one a single node if they are deployed as static pods. Otherwise, an existing scheduler distributes them across an existing cluster.
I do like "control node" for its simplicity. But, when I think of "node," I think of a kubelet on a machine. And sometimes the above components run in another Kubernetes cluster, so "node" might be misleading.
I kind of like "control replica," but it's a mouthful, as is "control node." If we're going to throw out "master," why not considering throwing out "control plane" as well? Is there a more concise alternative?
What does Kubernetes translate to?
Pilot, or shipmaster <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fclassic.studylight.org%2Flex%2Fgrk%2Fview.cgi%3Fnumber%3D2942&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128203992&sdata=dvgtEvyFGE%2FsNORgfJDCa9WxvIrZxbtV99770sLis%2Fw%3D&reserved=0>. So if 'master is short for the latter, and we don't like it, how about pilot?
Daniel
On Thu, May 16, 2019 at 10:49 AM 'Michael Taufen' via kubernetes-sig-cluster-lifecycle <kubernetes-sig-cluster-life...@googlegroups.com> wrote:
+1
Maybe "control node?"
Thinking in terms of control-plane and data-plane is more accurate anyway, "master" is ambiguous and also a misnomer as it suggests the control plane components must run on the same machine.
Whatever we pick it should be short and easy to say, and make sense the first time you hear it. I think this is half the reason people still use "master."
From: Fabrizio Pandini
<fabrizi...@gmail.com>
Date: Wed, May 15, 2019 at 11:04 PM
To: kubernetes-sig-cluster-lifecycle
+1
Fyi during HA work we are trying to use consistently control-plane node ("bootstrap control-plane node" and "secondary control-plane nodes" or "joining control-plane node" when referring to the init/join workflow).
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/8ca618fd-3413-4a5b-8e2b-acd4cee3416a%40googlegroups.com <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fkubernetes-sig-cluster-lifecycle%2F8ca618fd-3413-4a5b-8e2b-acd4cee3416a%2540googlegroups.com&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128213986&sdata=5KG6%2BO%2FgK3%2BIEqPGA4o99SpB6SH1YVS5ZgSMi%2BSULEc%3D&reserved=0>.
For more options, visit
https://groups.google.com/d/optout <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128213986&sdata=6SGT5YRIxsC4NYhhu4Tnqw9sxOklivcKG5JDFfcw56E%3D&reserved=0>.
--
Michael Taufen
Google SWE
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
kubernetes-sig-cluster-lifecycle+unsubscribe@googlegroups.com <mailto:kubernetes-sig-cluster-lifecycle+unsubscribe@googlegroups.com>.
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAHJadQ%2B0eXL49TZjS-cqfqyJo2UqdTYrEQPGmY1ELAu6Cca5fg%40mail.gmail.com <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fkubernetes-sig-cluster-lifecycle%2FCAHJadQ%252B0eXL49TZjS-cqfqyJo2UqdTYrEQPGmY1ELAu6Cca5fg%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128223977&sdata=s%2FzAnywWJJwQMu3PkCX7JcGOgqb2FCWgMytX3W148ng%3D&reserved=0>.
For more options, visit
https://groups.google.com/d/optout <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128223977&sdata=dyEXWr5gdX9J%2Bh32PcMMdM9qnz2STzX0k0f43zwMeJ0%3D&reserved=0>.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
kubernetes-sig-cluster-lifecycle+unsubscribe@googlegroups.com.
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAMAYzbCj5E%3D%3D0k-bEC2ogC8v1yW_H%3DfuGtKe6ar703cFi9Kz4Q%40mail.gmail.com <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fkubernetes-sig-cluster-lifecycle%2FCAMAYzbCj5E%253D%253D0k-bEC2ogC8v1yW_H%253DfuGtKe6ar703cFi9Kz4Q%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128233971&sdata=wq5z%2BB1IN8BjMvqCNfE1yN4AxfbS5ea%2BIoynFx7T%2BtY%3D&reserved=0>.
For more options, visit
https://groups.google.com/d/optout <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128233971&sdata=sdyZD8KXtDJDeljqpEBAf67%2B6CnaAiUlx80y3ccgKRM%3D&reserved=0>.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
kubernetes-sig-cluster-lifecycle+unsubscribe@googlegroups.com.
To post to this group, send email to
Cc: Fabrizio Pandini <fabrizi...@gmail.com>, kubernetes-sig-cluster-lifecycle <kubernetes-sig-cluster-life...@googlegroups.com>
Subject: Re: The way we discuss control plane members
Typically, apiserver/scheduler/controller-manager are deployed one a single node if they are deployed as static pods. Otherwise, an existing scheduler distributes them across an existing cluster.
I do like "control node" for its simplicity. But, when I think of "node," I think of a kubelet on a machine. And sometimes the above components run in another Kubernetes cluster, so "node" might be misleading.
I kind of like "control replica," but it's a mouthful, as is "control node." If we're going to throw out "master," why not considering throwing out "control plane" as well? Is there a more concise alternative?
What does Kubernetes translate to?
Pilot, or shipmaster <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fclassic.studylight.org%2Flex%2Fgrk%2Fview.cgi%3Fnumber%3D2942&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128203992&sdata=dvgtEvyFGE%2FsNORgfJDCa9WxvIrZxbtV99770sLis%2Fw%3D&reserved=0>. So if 'master is short for the latter, and we don't like it, how about pilot?
Daniel
On Thu, May 16, 2019 at 10:49 AM 'Michael Taufen' via kubernetes-sig-cluster-lifecycle <kubernetes-sig-cluster-life...@googlegroups.com> wrote:
+1
Maybe "control node?"
Thinking in terms of control-plane and data-plane is more accurate anyway, "master" is ambiguous and also a misnomer as it suggests the control plane components must run on the same machine.
Whatever we pick it should be short and easy to say, and make sense the first time you hear it. I think this is half the reason people still use "master."
From: Fabrizio Pandini
<fabrizi...@gmail.com>
Date: Wed, May 15, 2019 at 11:04 PM
To: kubernetes-sig-cluster-lifecycle
+1
Fyi during HA work we are trying to use consistently control-plane node ("bootstrap control-plane node" and "secondary control-plane nodes" or "joining control-plane node" when referring to the init/join workflow).
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/8ca618fd-3413-4a5b-8e2b-acd4cee3416a%40googlegroups.com <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fkubernetes-sig-cluster-lifecycle%2F8ca618fd-3413-4a5b-8e2b-acd4cee3416a%2540googlegroups.com&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128213986&sdata=5KG6%2BO%2FgK3%2BIEqPGA4o99SpB6SH1YVS5ZgSMi%2BSULEc%3D&reserved=0>.
For more options, visit
https://groups.google.com/d/optout <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128213986&sdata=6SGT5YRIxsC4NYhhu4Tnqw9sxOklivcKG5JDFfcw56E%3D&reserved=0>.
--
Michael Taufen
Google SWE
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAHJadQ%2B0eXL49TZjS-cqfqyJo2UqdTYrEQPGmY1ELAu6Cca5fg%40mail.gmail.com <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fkubernetes-sig-cluster-lifecycle%2FCAHJadQ%252B0eXL49TZjS-cqfqyJo2UqdTYrEQPGmY1ELAu6Cca5fg%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128223977&sdata=s%2FzAnywWJJwQMu3PkCX7JcGOgqb2FCWgMytX3W148ng%3D&reserved=0>.
For more options, visit
https://groups.google.com/d/optout <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128223977&sdata=dyEXWr5gdX9J%2Bh32PcMMdM9qnz2STzX0k0f43zwMeJ0%3D&reserved=0>.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAMAYzbCj5E%3D%3D0k-bEC2ogC8v1yW_H%3DfuGtKe6ar703cFi9Kz4Q%40mail.gmail.com <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fkubernetes-sig-cluster-lifecycle%2FCAMAYzbCj5E%253D%253D0k-bEC2ogC8v1yW_H%253DfuGtKe6ar703cFi9Kz4Q%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128233971&sdata=wq5z%2BB1IN8BjMvqCNfE1yN4AxfbS5ea%2BIoynFx7T%2BtY%3D&reserved=0>.
For more options, visit
https://groups.google.com/d/optout <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128233971&sdata=sdyZD8KXtDJDeljqpEBAf67%2B6CnaAiUlx80y3ccgKRM%3D&reserved=0>.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/tencent_3C79EBA6D9A20BA243FAAD09%40qq.com <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fkubernetes-sig-cluster-lifecycle%2Ftencent_3C79EBA6D9A20BA243FAAD09%2540qq.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128243966&sdata=d9zADyznsSAWJml60zPyLN7hFEilNpLZxj2%2BfzMeS9A%3D&reserved=0>.
For more options, visit
https://groups.google.com/d/optout <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Cakutz%40vmware.com%7C8251ae8e548740056a2608d6da603790%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636936504128243966&sdata=JfWAHBRtlUsR%2FrHRRaLLeQqJj1Baml26vB2TpDaqRtQ%3D&reserved=0>.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cluster-lifecycle+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-sig-cluster-life...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/A395BCB3-7BF1-4D50-8DCD-6FBF8D3964F1%40vmware.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAFQm5yTpdDCZS5WoabGM9rX_vHdFZoYmaKkpNLHpZUvASR-a0g%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-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/4854B942-DA89-482D-8D68-894D1AB5D8B0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAB_J3bYRN6bzMra6dTj7bAA6MZFVgVjLx%2Behw2BZXGeZd3irQA%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-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAFto3a2We4G060SavB4Zh1Xc-MKOux24rJSyDsFLUdh97XLxog%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-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAKCBhs5vG%3D-sxqzXbkrWr0pxgejOe3po6teHUDqSK%2B9%3DG5_wAg%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-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAO_RewYtRRmB_NyZ50rhPGpMCK%2B6rywcJjpdXqw_Da-x_QVjEw%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-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/f16b0f4a-21ae-4f78-a20f-129c7a965ae7n%40googlegroups.com.
On Jun 12, 2020, at 10:55 PM, Stephen Augustus <steph...@agst.us> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAOqU-DScOP9vBcjH8W%2B-cRZOF8GHRS3VM-usbPN1e0n_uHHGZg%40mail.gmail.com.