Updates on MEP-17. by Gerrit91 · Pull Request #361 · metal-stack/website

Gerrit91 · 2026-10-05T20:09:35Z

Description

After our MEP-4 journey, we realized we can even do more with MEP-17.

Used AI-Tools ✨

None used for generation

netlify · 2026-10-05T20:09:41Z

✅ Deploy Preview for metal-stack-io ready!

Name	Link
🔨 Latest commit	`9600f81`
🔍 Latest deploy log	https://app.netlify.com/projects/metal-stack-io/deploys/6ac8bb6d6c56e80008c88963
😎 Deploy Preview	https://deploy-preview-361--metal-stack-io.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

iljarotar

Mostly stylistic remarks. Content-wise very good.

A minor nit: I prefer markdown files where each sentence starts in a new line. It's easier to review.

One question regarding management switches. Do we also want those to be "reconciled" via API? If so, maybe also add them where you mention spines and exits.

iljarotar · 2026-10-06T06:55:13Z

+
+With the current state we see the following room for improvements:
+
+- `Switch` resources should be applied declaratively at the API through deployment by the Admin API. Instead of registering a switch, the switch queries the API on a specific switch entity provided as a startup configuration. This kind of "reverses" the registration procedure. The metal-core establishes a stream connection to the API for a given switch ID and then reconciles the given switch desired state definition. This approach has the following advantages:


... and then reconciles the given switch desired state definition.
I don't understand the grammar of this sentence.

I reordered this sentence a bit, maybe you can check again if it is better now?

iljarotar · 2026-10-06T07:03:15Z

+- Figure out what has to go into the port configuration in order to achieve FRR configuration scenarios we have on spines and exit switches
+- Check what special scenarios we have for static port configuration (support tenant VRF statically on a specific port, maybe black hole configuration instead of default PXE VRF?)
+- Check if we can really drop machine connections: Do we really want to always evaluate the neighbors all the time?
+- Elaborate the switch port change to on the leaf switch into the tenant VRF: The metal-hammer currently sends the `InstallationSucceeded` message to the server, but when the switch gets notified immediately through stream, it might break the network connection prematurely such that the metal-hammer does not retrieve the response in time causing a crash.


Elaborate the switch port change to on the leaf switch into the tenant VRF

I don't understand this sentence.

Rephrased, is it better now?

…ged.

Gerrit91 · 2026-10-06T08:43:48Z

Thanks for the review. We now have every sentence in a single line.

I am not sure if we also include the management switches into the "reconciliation"? I think you need to tell me if this would be possible. I changed the MEP now that we do it for the management network, too.

mwindower · 2026-10-06T08:45:03Z

This approach could be extended to manage the lifecycle of a switch, mirroring how we already handle machines:

ONIE boot: The switch boots into ONIE and requests an address via DHCP (like "PXE booting" for machines).
Provisioning: The switch receives a NOS image and a ZTP script + controller setup.
Registering: The switch registers itself and waits until it is assigned a role.
Waiting: The switch waits for an allocation.
Allocation: The switch is assigned to a partition, rack and role. A controller on the switch then reconciles it to the desired state.
Freeing: The switch's configuration is removed and it is reset back to ONIE.
Replace: A defective switch is marked for replacement, and the new switch takes over its identity and desired state. (this one only applies to switches)

iljarotar · 2026-10-06T11:31:23Z

 - Check what special scenarios we have for static port configuration (support tenant VRF statically on a specific port, maybe black hole configuration instead of default PXE VRF?)
 - Check if we can really drop machine connections: Do we really want to always evaluate the neighbors all the time?
- Elaborate the switch port change to on the leaf switch into the tenant VRF: The metal-hammer currently sends the `InstallationSucceeded` message to the server, but when the switch gets notified immediately through stream, it might break the network connection prematurely such that the metal-hammer does not retrieve the response in time causing a crash.
+- Elaborate how the port reconfiguration on machine allocation can be orchestrated: The metal-hammer currently sends the `InstallationSucceeded` message to the server, but when the switch gets notified immediately through stream, it breaks the network connection prematurely such that the metal-hammer does not retrieve the response in time causing a crash.


Actually, the behavior you describe here is not something we know for sure. I think that, in general, we need to find a clean solution for the timing of the port configuration. It's not strictly related to MEP-17.

iljarotar · 2026-10-06T11:48:23Z

This approach could be extended to manage the lifecycle of a switch, mirroring how we already handle machines:

* **ONIE boot**: The switch boots into ONIE and requests an address via DHCP (like "PXE booting" for machines).

* **Provisioning**: The switch receives a NOS image and a ZTP script + controller setup.

* **Registering**: The switch registers itself and waits until it is assigned a role.

* **Waiting**: The switch waits for an allocation.

* **Allocation**: The switch is assigned to a partition, rack and role. A controller on the switch then reconciles it to the desired state.

* **Freeing**: The switch's configuration is removed and it is reset back to ONIE.

* **Replace**: A defective switch is marked for replacement, and the new switch takes over its identity and desired state. (this one only applies to switches)

Interesting thought. Do you think we should extend MEP-17 to include such lifecycle management? If so, I'd like to discuss each step in detail. For example, I'm not sure if Waiting, Registering and Allocation should be separate steps.

Gerrit91 · 2026-10-06T12:44:01Z

Interesting thought. Do you think we should extend MEP-17 to include such lifecycle management? If so, I'd like to discuss each step in detail. For example, I'm not sure if Waiting, Registering and Allocation should be separate steps.

Also this contradicts a bit with the idea of the declarative API because the role is already assigned by the admin.

Gerrit91 · 2026-10-09T10:05:19Z

Maybe someone else can take over this PR or we can merge it in this state and then someone re-opens another one containing additional topics like "provision without Ansible", "state machine"?

Updates on MEP-17.

5f8a173

metal-robot Bot added the area: documentation Affects the documentation area. label Oct 5, 2026

metal-robot Bot added this to Development Oct 5, 2026

Reorder.

14549d0

Gerrit91 requested review from iljarotar and majst01 October 5, 2026 20:16

iljarotar reviewed Oct 6, 2026

View reviewed changes

Gerrit91 added 3 commits October 6, 2026 09:13

Move every sentence to a single line for better review.

0d3b6ab

Review comments.

5860936

Remove sentence about unmanaged mgmt switches and add instead to mana…

7a5d58c

…ged.

iljarotar reviewed Oct 6, 2026

View reviewed changes

Review comments.

9600f81

Gerrit91 marked this pull request as ready for review October 9, 2026 10:01

Gerrit91 requested a review from a team as a code owner October 9, 2026 10:01

iljarotar approved these changes Oct 9, 2026

View reviewed changes

iljarotar merged commit 070cad3 into main Oct 9, 2026
5 checks passed

iljarotar deleted the mep-17-update branch October 9, 2026 10:05


		With the current state we see the following room for improvements:

		- `Switch` resources should be applied declaratively at the API through deployment by the Admin API. Instead of registering a switch, the switch queries the API on a specific switch entity provided as a startup configuration. This kind of "reverses" the registration procedure. The metal-core establishes a stream connection to the API for a given switch ID and then reconciles the given switch desired state definition. This approach has the following advantages:

Conversation

Gerrit91 commented Oct 5, 2026

Description

Used AI-Tools ✨

Uh oh!

netlify Bot commented Oct 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for metal-stack-io ready!

Uh oh!

iljarotar left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

iljarotar Oct 6, 2026

Choose a reason for hiding this comment

Uh oh!

Gerrit91 Oct 6, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

iljarotar Oct 6, 2026

Choose a reason for hiding this comment

Uh oh!

Gerrit91 Oct 6, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Gerrit91 commented Oct 6, 2026

Uh oh!

mwindower commented Oct 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iljarotar Oct 6, 2026

Choose a reason for hiding this comment

Uh oh!

iljarotar commented Oct 6, 2026

Uh oh!

Gerrit91 commented Oct 6, 2026

Uh oh!

Gerrit91 commented Oct 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

netlify Bot commented Oct 5, 2026 •

edited

Loading

mwindower commented Oct 6, 2026 •

edited

Loading