[08:22] <qiujunting> hello all
[08:23] <qiujunting> i have a probelm about cloud-init
[08:24] <qiujunting> the init-local and init are success, but the config and final are not excuted
[08:25] <qiujunting> i need our group help
[14:27] <minimal> spotted a behaviour with the Ec2 data source which could be argued whether or not its a bug - basically if you boot a c-i enabled image on KVM/Qemu where the Ec2 DataSource happens to be enabled then a dmi-related warning appears in the cloud-init.log but also on the console during boot. Basically with KVM/QEMU /sys/class/dmi/id/systemuuid doesn't exist and if you don't have "dmidecode" installed then the Warning is triggered
[14:28] <minimal> only the Ec2 DataSource triggers this
[14:29] <minimal> s/systemuuid/system_uuid/
[14:53] <rharper> minimal: that sounds expected ...  Ec2 configures instance system UUID to start with 'ec2'  ...  and cloud-init needs to read that to identify it's booting on Ec2
[14:54] <rharper> there are exactly two ways of reading system_uuid that I know of, sysfs and dmidecode
[14:55] <rharper> Azure and a few other datasources also use DMI fields, not system_uuid, but machine or some other value that the hosting provider sets...
[14:55] <rharper> w.r.t your booting under KVM and no sys/class/dmi   do you have a custom kernel it may not have enabled the sysfs dmi attributes
[15:17] <minimal> rharper: yes, the issue is that if dmidecode is installed there is no warning but if dmidecode is not installed there is a warning, despite the fact that system-uuid does not exist in both cases.
[15:18] <minimal> its not missing /sys/class/dmi on KVM, its specifically missing /sys/class/dmi/id/system-uuid
[15:20] <minimal> other providers like Azure do check system-uuid but do so after other checks (which then "abort") and so don't hit this issue
[15:37] <rharper> minimal:  so the system-uuid read out of sysfs is from /sys/class/dmi/id/product_uuid   which, may not be set by default in qemu ,, you can construct the command line qemu-system-x86-64 -smbios type=1,uuid=$UUID ... this will show up in table Type 1 as the UUID field, which should map to the /sys/class/dmi/id/product_uuid value in the guest sysfs
[15:44] <Odd_Bloke> falcojr: You manually added the Vultr changelog lines in each release branch, I assume?
[15:44] <Odd_Bloke> falcojr: In case you didn't see, by the way, I've requested changes on the hirsute branch.
[15:45] <falcojr> Odd_Bloke:  yes, I manually added the changes
[15:47] <Odd_Bloke> falcojr: And you saw cherry-pick conflicts too, I assume, in the .po[t]? timestamps?
[15:48] <falcojr> yes, I thought(?) I resolved those
[15:49] <Odd_Bloke> falcojr: Yep, I'm ensuring I can replicate what you produced as part of my review.
[16:22] <Odd_Bloke> falcojr: I'm wondering if we want to fix this in impish as ubuntu2 and then use that as the "base" version in the SRU?
[16:25] <falcojr> Odd_Bloke: what do you mean by base version? Like how would fixing it there as a new version impact the rest of the SRU?
[16:26] <Odd_Bloke> falcojr: As in, fix it in impish, then s/ubuntu1/ubuntu2/ in the SRU branches.
[16:26] <Odd_Bloke> (I'm working on the impish fix right now.)
[16:28] <falcojr> why would the SRU branches take ubuntu2 if they never had ubuntu1?
[16:28] <falcojr> s/they never had/we never released
[16:29] <Odd_Bloke> Semantically, we're expressing that we're backporting the ubuntu2 version in the devel release.
[16:30] <paride> speaking of the .po files, I wanted to check why the translations have been lost across releases
[16:30] <Odd_Bloke> "21.2-3-g899bfaa9-0ubuntu2~20.10.1" is saying "this is the first backport of 21.2-3-g899bfaa9-0ubuntu2 to 20.10"
[16:31] <Odd_Bloke> falcojr: https://github.com/canonical/cloud-init/pull/900
[16:33] <falcojr> approved
[16:33] <paride> https://github.com/canonical/cloud-init/commit/bdfb4dabaea72adef196b99eda770a72c2e8decd
[16:33] <paride> this is the commit that dropped the translations at some point
[16:34] <paride> so we have a populated debian/po directory in the ubuntu/xenial branch, an empty one in ubuntu/bionic, and now an almost-empty one in ubuntu/devel
[16:35] <paride> well now I see why Scott did it: the templates were only about the removed grub package
[16:35] <paride> so I think it's all good