Skip to content

Commit 6a600bd

Browse files
authored
Merge pull request #7902 from richardcase/feat_group_proxying
📖 Add alternative communication patterns feature group
2 parents 31b3724 + 0139b60 commit 6a600bd

File tree

1 file changed

+57
-0
lines changed

1 file changed

+57
-0
lines changed
Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
---
2+
title: Feature Group for alternative communication patterns
3+
authors:
4+
- "@fgutmann"
5+
- "@richardcase"
6+
reviewers:
7+
- "@fgutmann"
8+
- "@richardcase"
9+
- "@alexander-demicev"
10+
creation-date: 2023-01-11
11+
last-updated: 2023-01-26
12+
status: proposed
13+
see-also:
14+
- https://github.com/kubernetes-sigs/cluster-api/issues/6520
15+
- https://docs.google.com/document/d/1j4sCPGO_0e1G-IyiI_8s98R3RVrYsgY9n0VFcde3ELo/edit#heading=h.lcjlkg7scook
16+
---
17+
# Alternative Communication Patterns Feature Group
18+
19+
This document briefly outlines the scope, communication media, and stakeholders for a formal Feature Group dedicated to defining a Cluster API-approved solution for supporting alternative communication patterns. Currently Cluster API assumes that it can initiate direct connections to all child clusters and/or to an infrastructure control plane. For some users / usage scenarios this isn't possible (technically or by policy) and so this group will investigate alternatives to enable these types of usage scenarios.
20+
21+
## User Story and Problem Statement
22+
23+
From [discussion](https://github.com/kubernetes-sigs/cluster-api/issues/6520#issuecomment-1341517675) this group will consider 3 uses cases:
24+
25+
1. A solution for managed clusters only, which does not require API-server connectivity from CAPI at all.
26+
1. The "common cluster as a service offering" scenario where only the workload clusters' worker nodes are in a different network.
27+
1. The scenario where a management cluster manages workload clusters (including control plane nodes), which are in a different network than the management cluster.
28+
29+
> Although use case 3 will likely be the main focus.
30+
31+
## Scope
32+
33+
The scope of this group will be the following:
34+
35+
1. Investigate alternative communication patterns in relation to the user stories
36+
2. Create a proof-of-concept (if applicable)
37+
3. Create a CAPI proposal with recommended changes (if applicable)
38+
4. Implement the proposal (if applicable)
39+
40+
## Communication
41+
42+
We will bi-weekly meet on Fridays @ 09:00 PT on [Zoom][zoomMetting]. [Convert to your timezone](https://dateful.com/convert/pst-pdt-pacific-time?t=01&tz2=Greenwich-Mean-Time-GMT). Meeting notes will be documented in this [Google Doc][meetingnotes].
43+
44+
Regular, summarized updates of group progress will be provided during weekly Cluster API office hours on Wednesdays @ 10:00 PT on [Zoom][zoomMeeting].
45+
46+
Chat with stakeholders on Kubernetes [Slack](http://slack.k8s.io/) in the [cluster-api](https://kubernetes.slack.com/archives/C8TSNPY4T) channel.
47+
48+
## Stakeholders
49+
50+
Primary Stakeholders are listed below:
51+
52+
- Florian Gutmann (@fgutmann, AWS)
53+
- Richard Case (@richardcase, SUSE)
54+
- Alexander Demicev (@alexander-demicev, SUSE)
55+
56+
[zoomMeeting]: https://zoom.us/j/861487554
57+
[meetingnotes]: https://docs.google.com/document/d/1Q1ShR7H_W1EUYOB_5MCtM91kDuGg59bmuVcR4qkwaeA/edit?usp=sharing

0 commit comments

Comments
 (0)