Comment 6 for bug 1899487

> On the flip side the presence of the MTU key in the OpenStack
> metadata cannot be used as an indicator for intent from either the
> system or the user that the DHCP server should not be providing the
> MTU either.
>
> Looking at the commit that changed the behaviour in OpenStack the
> intent of the original code was to always provide the MTU value in
> the metadata regardless of network type, the fact that it showed as
> `null` was a bug.
>
> Up until 2017 the default for the OpenStack controlled DHCP server
> was to always provide an MTU. In 2017 the ability to control this
> behaviour was removed and from that point onward it always provides
> an MTU.
>
> The user has no way of influencing the contents of the OpenStack
> network metadata, apart from downgrading to a 5 year old version.
>

Before we continue suggesting that cloud-init should somehow guess
what OpenStack meant to do with network configuration it provided to
cloud-init I'd like to make sure we discuss what we're suggesting.

If we can guess that an OpenStack which sent an MTU really didn't
mean for cloud-init to use this MTU because the DHCP server might
also send an MTU, can we not guess that the IP address it sent us
wasn't the correct one and instead we should add .1 to the lowest
octet?

I'm being pendantic here to make a point. OpenStack is the "Oracle"
here; just like MAAS, or Ec2 or Azure. The network configuration it
provides to the guest is meant to be taken as it is provided.

If the configuration is sub-optimal should not the cloud itself
resolve this?

Has there been any attempt to ask in OpenStack upstream why the MTU
plumbing/control was removed? If a specific MTU is needed for a
network in OpenStack, should that not be configured in OpenStack such
that the MTU value is either statically provided in the
network-data.json sent *or* update the DHCP server running on that
network to provide the correct value?

> I don't see an easy way of overriding cloud-inits default behaviour
> by adding additional configuration through vendor data either.

This is correct. Network-config cannot be part of user-data or
vendor-data; the network needs to be configured prior to cloud-init
fetching/reading this data (which may be URLs to remote cloud-config).

>
> Perhaps adding a cloud-init config stanza for how the OpenStack
> source driver should interpret the presence of MTU in the network
> metadata could be a path to retain compability with anyone relying
> on the current behaviour and at the same time providing a way
> forward for everyone else?
>
> Meanwhile instances are configured to obtain an address dynamically
> but stuck with a static value for MTU forever, and not being able to
> adjust to changes being made to the environment without manual
> intervention to individual instances.

If the network-data.json provided by the metadata service is not
sufficient and you cannot change this service one can provide a
network configuration in a ConfigDrive.