> So I would suggest that whenever OpenStack eludes to dynamic configuration
> being in play cloud-init should not write the MTU value into the on-disk
> configuration but let it be configured by dynamic network configuration
> protocol.
>
> What do you think?
I would argue the opposite. The existing behavior is that the MTU provided
by the network-data.json is the source of truth. Cloud-init itself cannot
determine whether the DHCP service provides MTU or not, nor whether the MTU
provided in the DHCP response is infact the desired MTU. Further, for
cloud-init now to start ignoring MTU if DHCP is present would break existing
users who's DHCP server either does not provide MTU or provides an incorrect
value.
If network-data.json MTU value is null, then I think it all of this works the
way you want, correct? Looking at the bug which fixed this always null value
should it not be enhanced to only set this MTU value if the DHCP service on
the network is not providing an MTU?
** Changed in: cloud-init
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899487
Title:
cloud-init hard codes MTU configuration at initial deploy time
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1899487/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
