for clients the network property "vrfshared" is always false

[mreiger]

When displaying a network with property vrfshared: true with metalctl network list --id=<network-id> -o yaml it falsely claims vrfshared is set to false:

$ metalctl network list --id=<network-id> -o yaml
- changed: "2020-05-08T05:37:46.487Z"
  created: "2020-03-10T14:22:21.823Z"
  description: ""
  destinationprefixes:
    - <...>
  id: <network-id>
  labels: {}
  name: <network name>
  nat: true
  parentnetworkid: null
  partitionid: ""
  prefixes:
    - <network prefix>
  privatesuper: false
  projectid: ""
  underlay: false
  usage:
      availableips: 16
      availableprefixes: 0
      usedips: 15
      usedprefixes: 0
  vrf: <vrf number>
  vrfshared: false

[mreiger]

The culprit may also be https://github.com/metal-stack/metal-api.

[Gerrit91]

Good finding. It's definitely coming from the metal-api because the vrfshared property does not get set in the network response. Therefore it comes with null for this property which the metalctl client always interprets as false. It looks like we do not even persist this property in the database, we only use it when creating a new network to check whether it can have the same VRF ID like another network or not.

There are three possibilities to solve this, I assume:

• Persist the property in the database
• Dynamically find out the state of this property and add it to the response
• Remove property from this response and only keep it in the network create request

[majst01]

I think we can only decide between:

• persist in the metal.Network entity
• remove the property from the response

As this is only a flag for network creation and not used later in any case, i strongly vote removing this property from the response, and dont show it in the describe output. Removing from the response is also more difficult, because we need to modify/split the NetworkImmutable struct therefore.