[13:26] Odd_Bloke, I've been able collect the logs of an i3.metal instance failing to reboot following your suggestion of attaching the volume to another instance [13:26] Odd_Bloke, https://bugs.launchpad.net/cloud-init/+bug/1841182 [13:26] Launchpad bug 1841182 in cloud-init "cloud-init fails when rebooting EC2 i3.metal instances" [Undecided,New] [13:26] there is my bug report [13:28] Thanks! [15:53] Odd_Bloke: or rharper if you get a chance to review my SRU branches into Xenial, Bionic and Disco, landing those are the only thing blocking us from moving forward with SRU Xenial: https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371685 Bionic: https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371686 Disco: [15:53] https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371687. The only thing unique there is my enablement of Exoscale in debian/cloud-init.templates [15:54] right [16:00] blackboxsw: I looked at xenial/bionic, both have changelog entries mentioning enabling Aliyun, which I think you meant exoscale, right ? [16:02] rharper: grr right fixing [16:15] git.lp is super slow again today [16:45] rharper: all fixed bionic xenial and disco debian/changelog s/AliYun/Exoscale [16:45] and retagged [16:45] ok, I'll re review [18:17] blackboxsw: one more fix up on the sru branches in the cloud-init.templates [18:44] rharper: per the cloud-init.templates, there is a mix-n-match set of descriptions, some datasources say "Read from X metadata service", others say "X metadata services". [18:44] *shrug* ok [18:44] shall we update them all to be the same verbiage? [18:44] I wouldn't risk changing them [18:44] I'm not sure what happens if we do; isn't this debconf input or something ? [18:45] s/X metadata services/X metadata service/ [18:45] rharper: that particular line item is just the human readable description that you can see in the 'ncurses' TUI if running dpkg-reconfigure [18:46] maybe it's not ncurses anymore, but whatever the TUI is [18:46] so, we don't have to now; but I would like a tools/add-datasource script which manipulates/renders that file [18:46] that way, we don't have to manually edit that file each time [18:46] blackboxsw: so I'll rereview and approve [19:07] powersj: Odd_Bloke: just pushed sru templates to https://github.com/cloud-init/ubuntu-sru/tree/master/20190823 [19:07] blackboxsw, thx! [19:08] Odd_Bloke: it's t-minus 0 mins until end of week your time, but if you end up grabbing one of the sru-related bugs listed in https://github.com/cloud-init/ubuntu-sru/tree/master/20190823 just let me know [19:08] * blackboxsw was going to try looking at one of the cloud manual scripts to see if it needs to be extended to check for a specific bug in this release. (I imagine azure will have a bit) [19:09] blackboxsw: Ack, will check in a few minutes if I think there's something I can take care of before EO[DWM]. [19:10] * blackboxsw queues xenial/bionic and disco sru [19:59] Okie dokey SRU into xenial, bionic disco approved by vorlon. so it should be built shortly [19:59] woohoo [20:00] tribaal: for next week there should be cloud images with updated cloud-init 19.2.21 with exoscale enabled. If you do get a chance to peek at it on your platform, feel free to comment on the SRU bug: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1841099 [20:00] Launchpad bug 1841099 in cloud-init (Ubuntu) "SRU cloud-init (19.1.1 to 19.2.21): Xenial, Bionic, and Disco" [Undecided,New] [20:00] ... it better be well past tribaal's EOD [20:02] you'll need to: echo deb $mirror $(lsb_release -sc)-proposed main | [20:02] tee /etc/apt/sources.list.d/proposed.list; apt-get update [20:04] mirror=http://archive.ubuntu.com/ubuntu [20:08] blackboxsw: Cloud images won't include it until after the SRU is complete, right? Or am I misunderstanding what you're asking tribaal to do? [20:08] Odd_Bloke: agreed. but -proposed will have it. per my comment: echo deb $mirror $(lsb_release -sc)-proposed main | [20:08] 14:02 tee /etc/apt/sources.list.d/proposed.list; apt-get update [20:09] blackboxsw: Right, but "there should be cloud images with updated cloud-init 19.2.21 with exoscale enabled" is misleading, I think? [20:09] tribaal: will need to add a proposed apt-source to his instances to see and install updated cloud-init-19.2.21 and then run "sudo cloud-init clean --reboot --logs" to exercise the updated cloud-init [20:10] Odd_Bloke: ahh right sorry tribaal. That is misleading. there are a couple of steps to enable that new -proposed cloud-init in the image; 1. add -proposed apt source; 2. apt-get update; 3. sudo apt-get install cloud-init; 4: sudo cloud-init clean --reboot --logs; [20:13] we run the following script on a new vm https://github.com/cloud-init/ubuntu-sru/blob/master/bugs/lp-1797480.txt#L17-L23 [20:14] followed by cloud-init clean --logs --reboot. given that a new datasource is enabled, you might have to add Exoscale to /etc/cloud/cloud.cfg.d/90_dpkg.cfg [20:14] or dpkg-reconfigure cloud-init [20:15] Do we have docs on how to do this? [20:27] Odd_Bloke: I can add something to our SRU docs if needed, but we do have the following: https://cloudinit.readthedocs.io/en/latest/topics/datasources.html?highlight=datasource_list#adding-a-new-datasource [20:27] "Add your datasource name to the builtin list of datasources:" and "Enable datasource by default in ubuntu packaging branches:" [20:43] blackboxsw: I meant specifically on how people can test cloud-init from -proposed for us. [21:00] Odd_Bloke: I'll add a trello card, yeah we should add new section on the testing/debugging page simple on https://cloudinit.readthedocs.io/en/latest/topics/debugging.html [22:18] rharper: yeah for openstack network v2 I'll have to address network_state passthrough for v2 IBMCloud, ConfigDrive or OpenStack all use the adapted cloudinit.sources.helpers.openstack.py:convert_net_json helper to create NetworkState instances. So, it looks like this branch will be a bit bigger :/