[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2021-12-13 Thread Frode Nordahl
To add to Bretts comment in #21, the proposed workaround is only effective if you know about this situation beforehand. I.e. if you enabled the override through vendor data before deploying any Focal or newer instances. Another possible workaround is to preform a "cold migration". When Nova stop

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2021-11-23 Thread James Falcon
** 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 noti

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2021-11-10 Thread Frode Nordahl
Adding upstream OpenStack Nova to the bug to get their perspective on why the OpenStack datasource is exposing MTU when it knows that the network should be configured using DHCP ref Brett's question in #21. ** Also affects: nova Importance: Undecided Status: New -- You received this bu

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2021-11-09 Thread Brett Holman
Hi Alexander, Thanks for reopening. Sorry to hear about the instance loss. We have a short term fix, but I think we need to request a fix in Openstack for network_data.json as well. Currently cloud-init passes a configured MTU value to the renderers (netplan/systemd-networkd/etc), which in turn t

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2021-11-05 Thread Alexander Balderson
I'm going to re-open this bug after working through Openstack networking migration for OVS to OVN. I ran into an issue where the MTU set in netplan caused all my instances to be lost after the migration. While this can, and should, be documented, I also think that reducing places where instances c

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-12-14 Thread Launchpad Bug Tracker
[Expired for netplan.io (Ubuntu) because there has been no activity for 60 days.] ** Changed in: netplan.io (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-12-14 Thread Launchpad Bug Tracker
[Expired for cloud-init because there has been no activity for 60 days.] ** Changed in: cloud-init Status: Incomplete => Expired -- 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:

Re: [Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-15 Thread Ryan Harper
On Thu, Oct 15, 2020 at 10:45 AM Frode Nordahl <1899...@bugs.launchpad.net> wrote: > Ryan, thanks for those pointers, will check. I also see in #15 that > Bionic uses Fallback while Focal uses an actual ds, don't know why > though. > Bah, I *keep* forgetting, that Bionic does *NOT* read OpenStack

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-15 Thread Frode Nordahl
Ryan, thanks for those pointers, will check. I also see in #15 that Bionic uses Fallback while Focal uses an actual ds, don't know why though. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1899487 Tit

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-15 Thread Frode Nordahl
Adding some excerpts from cloud-init logs differences between Focal and Bionic, appears to be quite a bit difference in how config is handled. I also went back and compared if there were other differences like image properties or similar stuff that could find their way into qemu config, but found

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-15 Thread Ryan Harper
> I guess it's time for me to ask a question: is it cloud-init that > renders /etc/netplan/50-cloud-init.yaml? If so where does netplan > fit in when the difference is how that file is rendered and not > how it is interpreted. As you can see in #10 the mtu statement is > not in the file on bionic,

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-14 Thread Frode Nordahl
I can't let go of why the same version of cloud-init renders different config with the same data source. So a question: are there other data sources in use that we have not yet examined? Information from the hypervisor configuration trickling through the virtio drivers or something like that? I

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-14 Thread Frode Nordahl
> Hmm, however it should be the same version of cloud-init in either Bionic or Focal tests. Is this a netplan change? In the bionic image I have: $ dpkg -l | egrep "(cloud-init|netplan)" ii cloud-init 20.3-2-g371b392c-0ubuntu1~18.04.1 all Init scripts for

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-14 Thread Richard Harding
In our functional test we use Bionic images, and sure enough the netplan.yaml [9] written there does _NOT_ include the MTU! The OpenStack Metadata source remains the same [10]. Hmm, however it should be the same version of cloud-init in either Bionic or Focal tests. Is this a netplan c

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-14 Thread Frode Nordahl
Comment #8 made me think about why this works in our functional test, so I went to investigate that. In our functional test we use Bionic images, and sure enough the netplan.yaml [9] written there does _NOT_ include the MTU! The OpenStack Metadata source remains the same [10]. 9: ubuntu@banana-1:~

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-13 Thread Frode Nordahl
The CI artifact referenced in [6] in the previous comment was removed, the source can be viewed here: https://review.opendev.org/#/c/715132/4 /deploy-guide/source/app-ovn.rst -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-13 Thread Frode Nordahl
Richard, The "MTU controls in OpenStack have been removed" part pertains to the removal of the operator facing configuration option for the OpenStack DHCP server as to whether or not it should provide information about the network MTU in it's response to clients. Where the removal here means that

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-13 Thread Richard Harding
Frode, can you explain to me the OpenStack operator path here. I'm not familiar with how these adjustments are practically made. You mention "a operator to reduce the MTU available to instances" and "To maximize performance these clouds have configured their instances to use the maximum available

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-12 Thread Ryan Harper
> 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

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-12 Thread Frode Nordahl
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

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-12 Thread Ryan Harper
> 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 exis

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-12 Thread Frode Nordahl
That is an excellent question, I see that the example provided in the Nova documentation [0] provides `null` for the MTU. There are also a Nova bug 1746323 on the lack of actual API documentation for the OpenStack format metadata, so I guess they could expect no less than diverging implementations

[Bug 1899487] Re: cloud-init hard codes MTU configuration at initial deploy time

2020-10-12 Thread Ryan Harper
" # curl http://169.254.169.254/openstack/2018-08-27/network_data.json {"links": [{"id": "tapa035fb68-01", "vif_id": "a035fb68-010c-42e3-8da7-ea3c36a0d607", "type": "ovs", "mtu": 8942, "ethernet_mac_address": "fa:16:3e:31:26:f7"}], "networks": [{"id": "network0", "type": "ipv4_dhcp", "link": "ta