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
** 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
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
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
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
[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.
[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:
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
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
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
> 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,
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
> 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
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
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:
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.
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
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
> 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
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
> 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
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
" # 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":
23 matches
Mail list logo
