Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update network concept doc with network peering #256

Merged
merged 1 commit into from
Mar 20, 2024
Merged

Update network concept doc with network peering #256

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions docs/concepts/network-lifecycle.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,3 +24,20 @@ The valid `NetworkID` range can be configured using the `apiserver`s

When deleting a `Network`, the corresponding `NetworkID` is cleaned up
alongside the claiming `Network`.

## Network Peering

When creating network peering both `ironcore` `Network`s has to specify matching,
`spec.peerings` referencing each other respectively. A `ironcore` `Network` can be peered with
multiple `network`s in any namespcae.

Once specified `apinetlet` `NetworkPeeringController` validates if all the specified `network`s are in
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need an own reconciler for the Network peering or wouldn't it be just enough to extend the existing Network reconciler to ensure the peering information in the Network in the apinet group and update the ironcore Status once the peering was established.

Copy link
Contributor Author

@kasabe28 kasabe28 Mar 8, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Network peering is happening only with Available state networks, so I think we should have different reconciler for network peering. If we do it in existing Network controller we have to wait till both networks come Available and then do peering in same reconcile loop will not be possible.
@balpert89 do you have different thoughts for new controller?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes my suggestion was to separate this in a dedicated controller because of two reasons:

  • what happens when the peering partner network has not set the currently reconciling network in its peering reference? The reconcile request has to be requeued then and can block succeeding the loop for this particular network (and its partner). If the logic for peering is isolated in its own controller, the "normal" reconciliation can happen without changing its logic.
  • as @kasabe28 mentioned, the reconciliation should only happen once the network status is Available which is contradicting to the current network reconciler as this one is actually setting the status to Available.

`Available` state,they do exists and have matching `peerings`.

If validation is successful, `apinetlet` `NetworkPeeringController` updates `ironcore` `Network`
`status.peerings` with network peering `name`s and `spec.incomingPeerings` with valid
incoming peerings. Also `apinetlet` `NetworkPeeringController` updates `ironcore-net` `Network`
`spec.peeredIDs` with valid peered network's `providerID`'s.

Once `ironcore-net` `Network` is updated with `spec.peeredIDs`, `metalnetlet` `NetworkController`
updates `metalnet` `Network` `spec.peeredIDs` with corresponding `ironcore-net` `Network` `spec.peeredIDs`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the peering status I opened an issue in the the metalnet project to clarify if we actually can get any status information: ironcore-dev/metalnet#189

Loading