Automate or validate MetalLB BGP peer configuration for NICo sites

[mmou-nv]

Problem

NICo site bring-up can require operators to manually determine and configure MetalLB BGP peer values such as peer address and peer ASN. This is error-prone and tightly coupled to site controller node networking details.

When these values are wrong or missing, service exposure and downstream app synchronization can fail. Operators currently need to inspect node/network metadata and manually update site configuration.

Requested improvement

Provide a NICo-owned automation or validation workflow for BGP peer configuration.

This could either:

• Automatically discover the correct peer address and peer ASN for site controller nodes, then render the MetalLB configuration, or
• Provide a preflight validation job that fails early with actionable output when BGP peer data is missing or inconsistent.

Why this matters

BGP peer configuration is infrastructure-derived data. Operators should not have to manually copy values into site configuration if NICo can discover or validate them from the environment.

Possible shape

A preflight or reconciliation job could report:

• Node name
• Expected BGP peer address
• Expected peer ASN
• Current rendered peer configuration
• Whether MetalLB BGP peers are valid and accepted by the cluster

This would reduce manual bring-up steps and prevent configuration drift across sites.

[ajf]

I'm not quite sure how this can be accomplished - since NICo doesn't have any knowledge of kubernetes service definitions. This sounds like it's likely something that the kubernetes deployment system should be doing? Not everyone will deploy on k8s w/MetalLB. Whatever generates the MetalLB configuration should presumably also be generating the configuration for whatever config is needed? (I think right now it's, I think the NTP and DNS services?, everything else is hostname). @mmou-nv do you have any suggestion on how this should work?

Automatically discover the correct peer address and peer ASN for site controller nodes, then render the MetalLB configuration, or
Provide a preflight validation job that fails early with actionable output when BGP peer data is missing or inconsistent.

These things happen before NICo is even running.