Addition of gateway properties to Network

[FlorinPeter]

Summary

We propose the addition of two properties, default-gw-ipv4 and default-gw-ipv6, to the Network object in the onmetal-api. These properties will provide the ability to disable the automatic injection of the default gateway in the network. By introducing these properties, we aim to enhance the flexibility and control of network configurations for users of onmetal-api.

Objective

The objective of this proposal is to extend the functionality of the Network object by incorporating default-gw-ipv4 and default-gw-ipv6 properties. The addition of these properties will allow users to have finer-grained control over the default gateway injection within their networks.

Technical Implementation

To achieve this objective, we will make the following changes to the onmetal-api:
Modify the Network object to include the properties default-gw-ipv4 and default-gw-ipv6.
Implement validation checks to ensure that these properties are omitted when empty.
Update the network configuration process to respect the values of these properties and disable the automatic injection of the default gateway if they are specified.

Impact and Benefits

The addition of default-gw-ipv4 and default-gw-ipv6 properties to the Network object will offer the following benefits:
Flexibility: Users will have the ability to disable the automatic injection of the default gateway in their network configurations, providing greater flexibility in managing network routing.
Customization: By allowing users to specify their own default gateway settings, the onmetal-api becomes more adaptable to different networking requirements and scenarios.
Control: The properties enable users to have precise control over the behavior of default gateway injection, empowering them to fine-tune network configurations according to their specific needs.

[FlorinPeter]

CC @MalteJ @gehoern @agerlach-tsi @dnlvanco

[afritzler]

As we are currently revamping the networking in onmetal-api and onmetal-api-net it would be great to postpone this feature request after those changes have been merged.

Can you also elaborate a little bit more on the rationale behind this feature request?

The only 2 scenarios I can think of are:

1. Pointing to a NAT Gateway: Doing SNAT in a subnet instead of broadcasting the default routes (0.0.0.0/0 or ::/0). As we don't have a Subnet in our networking concept and have a dedicated NATGateway resource, I would like to better understand how this should work together.
2. VPN/Direct Connect to a private/on-prem Network: Routing traffic through some peered private network outside onmetal. As we don't support those scenarios from our API at the moment (except for peering Networks on onmetal-api level) this would be something which should be addressed once we have support for those kind of peerings.