[00:00] just uploaded latest cloud-init into Ubuntu focal 20.04 [ubuntu/focal-proposed] cloud-init 20.1-5-g67c8e53c-0ubuntu1 (Accepted) [14:24] Hello guys. I'm building RPM package in Fedora 31 with mock. Some "python36-xxx" like dependencies blocked build. Is there special reason to use python36-xxx instead of python3-xxx? Thanks! [16:31] xiaofwan: no; specific reason; the spec file needs some updates; [16:31] we have someone actively working on updating our spec to build with newer centos/fedora; [16:33] xiaofwan: the general plan would be for py2 support to remain only on stable-19.4; for py3, I suspect that centos7 would remain py2 as well, for master, py3, we can get it working with newer python; [16:52] rharper: make sense! Appreciate! [16:54] xiaofwan: another thing to note, historically, the unittest/make check hasn't been run in the rpmbuild due to hard-to-find depdenencies in the rpm repositories; I do have hope that rawhide or other newer Fedora repos have new enough versions to enable that; if you end up with something working, please consider submitting a PR https://github.com/canonical/cloud-init/pulls [16:59] rharper: Nice! I'm working on fixing 'make rpm/srpm' on my centos and fedora mock env. Of course, I'll send PR after that. :) [17:00] \o/ [18:00] Hi I am seeing a scenario where when I install cloudinit 19.1, then add 9 additional volume of 2 GB each (Toal 10 volume [9 additional + 1 boot volume]), cloud init local service is failing with http://paste.openstack.org/show/790124/ [18:00] With 8 volume everything goes well [18:01] Can anyone suggest something? [18:01] amansi26: it looks unrelated to storage add; you're datasource is no longer present; what datasource is normally present ? [18:02] ConfigDrive [18:03] is the config drive still attached after adding those volumes (is this hotplug, or offline add, and then start back up) ? [18:03] Didn't get you [18:05] Then I tried to manually make the services up. It was failing . So changed /lib/systemd/system/cloud-init-local.service with http://paste.openstack.org/show/790125/. Then rebooted . All the services are running [18:05] how do you attach your additional volumes; do you shut down the instance; run some commands to attach the volumes; start the instance back up; or do you run commands while instance is running, then reboot ? [18:06] I add the instance in running state itself [18:06] it's failing because it could not find your config drive [18:06] is it possible that while adding the new volumes this removed the config drive ? [18:07] no [18:07] well, are you sure ? [18:07] you only showed the log indicating that cloudinit did not find a datasource [18:07] If that will be the case it should fail for adding 8 volumes also [18:08] if you use config drive, it uses either 'CONFIG-2' or 'config-2' to find this on block devices [18:09] how can I check that? [18:10] cloud-init runs blkid -c /dev/null -o export [18:15] rharper: aah.. you got it write. datasource is getting removed and setting it to none [18:16] is that expected (the removal) ? [18:16] is this Openstack or IBM CLoud ? [18:16] I know that IBM Cloud has some first boot/second boot transitions w.r.t config drive, IIRC [18:16] no The removal is not expected [18:17] IBM Cloud [18:17] well, it may be expected [18:17] So you are suggsting 8 is the limit? [18:17] https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/DataSourceIBMCloud.py [18:17] no [18:18] just that the config drive "goes" away some times due to how IBM CLoud is provision [18:18] if you read the datasource docs there; it's "complicated" [18:19] Was IBM Cloud DataSource is recently introduced? [18:19] no, it's been here for a few years [18:20] initial release was March 2018 [18:21] Quite new then [18:21] relatively speaking, yes [18:21] vs. say OpenStack [18:21] I will try using IBM Cloud DataSource replacing configDrive [18:22] I'm confused [18:22] either you're on IBM cloud and we detect that we are on it; or you're on an OpenStack cloud that's not IBM CLoud [18:23] As a Datasource I am using ConfigDrive [18:25] cloud-init should detect whether you're on IBM CLoud (with a config drive) vs. just a ConfidDrive on Openstack [18:26] so if you're seeing ConfigDrive instead of IBMCloud; then either there's a bug in the detection, or there's been a change to IBM CLoud such that we no longer detect it properly [18:46] @blackboxsw, ok, I was wrong yesterday regarding the initrd. That's something I acutally did on purpose to be able to run the 4 cloud-init calls in the correct order. [18:47] @blackboxsw, and I can hardly do something different. I think the situation will evolve if someone starts a port of cloud-init for NetBSD. [18:47] @blackboxsw, but I don't think this is a serious problem. [19:04] ahosmanMSFT: Ill take a look, thanks [21:23] rharper: thanks, I updated the PR [21:30] ahosmanMSFT: cool! [23:24] Is there a way to build a deb package without running the unit tests? I am testing Azure telemetry, so I need to have an intentionally-buggy cloud-init to test our telemetry systems. I intentionally added a raise exception statement which will obviously cause provisioning failure. But I cannot build a deb package as it runs the unit tests and obviously fails. [23:24] Whenever `make deb` is run, it runs ./packages/bddeb. Looking at the file, I have no idea how it works and been spending the past few hours trying to find where the unit tests are actually invoked during debian package build. [23:27] So in order to build a buggy cloud-init deb package, I would need to disable unit testing during deb build. Thanks! :) [23:27] I don't think I've seen any standardized way to pass in build flags to disable tests [23:28] (I can't recall seeing non-standardized ways either, but that feels likely that someone has escape hatches..) [23:35] johnsonshi: is the package in question using debhelper? https://manpages.debian.org/jessie/debhelper/dh_auto_test.1.en.html "If the DEB_BUILD_OPTIONS environment variable contains nocheck, no tests will be performed. "