Add initial vnet-peering proposal #652
Conversation
github-actions
bot
added
documentation
docs/proposals/08-peering.md
Outdated
| @@ -0,0 +1,168 @@ | |||
| --- | |||
| title: VNet Peering | |||
There was a problem hiding this comment.
VNet is implementation detail and should be renamed.
docs/proposals/08-peering.md
Outdated
|
|
||
| --- | ||
|
|
||
| # OEP-NNNN: Your short, descriptive title |
docs/proposals/08-peering.md
Outdated
|
|
||
| ## Summary | ||
|
|
||
| Network peering is a crucial feature to allow users to route traffic between two onmetal networks. This OEP introduces a new API that allows the owner of both networks to express the consent to peering the networks explicitely and extends the existing `Network` API to reflect an active peering. |
There was a problem hiding this comment.
There is no 'owner' in a Kubernetes sense. If a resource representing peering exists, there should not be consent necessary.
docs/proposals/08-peering.md
Outdated
| - peering connects whole networks together | ||
| (vf get both network route set announced) |
There was a problem hiding this comment.
vf is implementation detail and should be removed.
|
|
||
| - peering connects whole networks together | ||
| (vf get both network route set announced) | ||
| - clear separation from transit gateways |
There was a problem hiding this comment.
What is the separation from transit gateway and in which factors do we differentiate? What are the characteristics we expect that are different?
docs/proposals/08-peering.md
Outdated
| namespace: customer-andre #optional could be another network of the same namespace | ||
| status: | ||
| ttl: 2023-02-15T19:00:00Z # omit if empty | ||
| state: -> pending because missing match |
There was a problem hiding this comment.
Please follow the api conventions: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#constants
docs/proposals/08-peering.md
Outdated
|
|
||
| ### Example | ||
|
|
||
| Let's suppose Manuel wants to peer his `Network` `manuels-network` with André's `Network` `mysupernetwork`. Let's also assume that Manuel's namespace is `customer-manuel` and André's namespace is called `customer-andre`. With that we get the following two `NetworkPeeringRequest`objects reflecting a successful peering of the two `Network`objects presented at the end. |
There was a problem hiding this comment.
Please remove your own names to keep this generic. Also, remove the usage of the word 'customer' - this is about the API and namespaces, not about customers (that will eventually be there for sure, but customer / IAM can only exist if we respect k8s namespaces and boundaries correctly).
docs/proposals/08-peering.md
Outdated
|
|
||
| ## Proposal | ||
|
|
||
| We propose using a new API called `NetworkPeeringRequests` and extending the `Network` API with a `status` reflecting the peering. For a peering to succeed, both owners of the two `Networks` that should peer, have to create a matching `NetworkPeeringRequest`. On successful peering, the `status` of the corresponding `Network` objects should be updated with the other `Network`s details. A `NetworkPeeringRequest` will also have a set time-to-live (ttl), so the system will be able to automatically clean up vacant or unmatched `NetworkPeeringRequest`objects. Always two matching `NetworkPeeringRequests` are required to enable peering. Important: `localNetworkRef` must match to other `remoteNetworkRef` and vice versa. |
There was a problem hiding this comment.
The type should be called NetworkPeering as it represents the peering. The Request suffix does not make sense here.
| namespace: customer-manuel | ||
| name: manuels-network | ||
| status: | ||
| peeredNetworks: |
There was a problem hiding this comment.
One resource should not modify another resource. We should have a separate resource to embody the peering. See https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#do-not-modify-the-referred-object
There was a problem hiding this comment.
we should probably enhance the network controller to check for matching NetworkPeering resources
|
Superseded by #676 |
Proposed Changes