=== Majost_ is now known as Majost [18:07] rharper: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/344546 is ready [18:07] i'll look at yours now [18:23] smoser: reviewing [19:01] smoser: reviewed, and i've updated my detect branch with your changes [19:11] http://paste.ubuntu.com/p/FWkpmcPRpB/ [19:11] What amount of begging do I need to do to get my fixes into trusty? rmadison tells me that trusty is stuck at 0.7.5. [19:11] rharper: ^ [19:11] whoa [19:12] my ^ was for the pastebin there [19:12] heh [19:12] ok [19:12] mgerdts: trusty though.. [19:12] mgerdts: drops a bomb on release day no less =) [19:12] sorry. :-) [19:12] nah [19:12] its going to remain stuck at 0.7.5... we'd have to do a SRU and cherry pick your changes. [19:12] it's a fair question [19:12] at least he didn't ask that in #ubuntu-release [19:12] i'd support helping you out there if you wanted to [19:12] :) [19:12] dpb1: lol [19:13] smoser: re paste, can I just take your test_util. change? I think I've just pushed the others [19:13] ie, if you want to get your datasource into a state your happy with and propose a merge to trusty, i'd be willing to help. [19:13] If you can shine a light down the right path, I'm happy to wander down it. [19:14] ok. I have a couple more changes that are pending. [19:14] rharper: probably yeah. as in i dont need you to take exactly my changes in the test cases if you have the same. [19:14] ok, I do [19:14] We need to figure out what to do about the post-first-boot network configuration. That bit one of our early adopters this week. [19:14] * rharper notices we have tests/unittests/test_util.py and cloudinit/tests/test_utils.py [19:15] Deployed a VM, booted once, then added a network. Was surprised it didn't work. [19:15] yeah, cloudinit/tests/ is new [19:15] and the preferred path to add things too [19:16] I thought that was for new files, but I guess we'll never migrate if we don't start putting stuff there [19:18] mgerdts: so... going down the trusty path [19:18] the first thing to do would be to checkout ubuntu/trusty [19:20] then in order to make changes, you have to do the debian/patches route. [19:21] ok, that path seems to be lit well enough for me to get started. [19:24] mgerdts: get code into a state your happy with, and then bug me, and i can help with the sort of busywork that it will entail [19:24] sounds good. I'll pick that up after my last two changes are are settled. [19:24] Happy release day, btw. [19:27] rharper: you'll push the udevadm_settle tests on top ther e? [19:28] did I not ? [19:28] ah, tox is done [19:28] now I'll push [19:29] smoser: it's there now was waiting on tox to finish [19:29] k [19:30] rharper: you've done some actual test with the code path ? [19:31] I've not revalidated with the refactor of calling util.udevadm_settle() vs subp([udevadm, settle]) [19:31] I can fire that up if you like [19:32] smoser: ^ [19:32] well before we upload it to bionci lets have *some* run :) [19:32] ok [19:32] do you want to land and we push a trunk package into some instances ? [19:32] or would you prefer a positive test on gce before landing with the current branch ? [19:32] it won't take long either way [19:32] some run or some fun? [19:33] well, just make sure not obviously broken. build a deb, install it, run some reboots. [19:34] k [20:05] ok, I've got two instances in reboot loop on europe-west1; hoping to catch a positive detection and a handful of continuously successful reboots with networking. [20:08] Hi all, I have a bug and MP for the NTFS mounting issues we've seen on RHEL when using cloud init on Azure: https://bugs.launchpad.net/cloud-init/+bug/1767002 and https://code.launchpad.net/~paul-meyer/cloud-init/+git/cloud-init/+merge/344538 [20:09] Ubuntu bug 1767002 in cloud-init "When stop(deallocate) and then start a RHEL 7.5 VM, cloud-init cannot mount /dev/sdb1 to /mnt." [Undecided,New] [20:09] When you have time, PTAL and let me know what you need... [20:10] this is blocking RH from supporting cloud-init on Azure... [20:14] paulmey: isn't that kernel missing the ntfs module or possible the mount tools? [20:15] we have ntfs-3g package installed on ubuntu [20:15] probably, but neither RH or SUSE want anything to do with NTFS [20:15] and of course ntfs kernel module loaded [20:15] (for good reasons) [20:15] so, what's the alternative? isn't that what you format the filesystem with on azure ? [20:16] way back when animals could still talk, Microsoft thought that they would only ever host Windows [20:16] so they 'prepare' the ephemeral drive by partitioning and formatting it NTFS and putting some files on it to warn for data loss [20:17] but this is part of how one can detect whether the disk is "new" or not, right ? [20:17] cloud-init uses that to detect a 'freshly prepared' ephemeral drive before nuking it and putting ext4 on there, because ntfs is silly [20:17] so I don't think it's so easy to ignore [20:17] for sure, but users could have put something on it [20:17] and we don't want to lightly nuke data [20:18] not on RHEL or SUSE they can't [20:18] because they have no way of mounting it [20:18] ok, then we'll need some distro related override here [20:19] alternatively, I was thinking of making this a datasource config flag? (whether or not to ignore mount errors) [20:19] but as you say, we could also have this as a flag on the distro class [20:20] or even move the method to the distro class? [20:21] if its datasource config, RHEL and SUSE can bake the config in their images ... [20:24] the datasource get's a distro object [20:24] so you can just ask distro.name [20:25] s/ask/use [20:25] :-) ok, so then if RHEL or SUSE, ignore errors? [20:26] errors being this specific 'NTFS not supported' error [20:26] paulmey: can you look in /proc/filesystesm ? [20:26] rather than going by distro? [20:26] not really [20:26] or did i tell you not to do that :) [20:26] because if the module is not loaded, it doesn't show up there yet [20:27] also, I think some distros now mount ntfs via fuse [20:27] oh. hm. [20:29] When I get time, I'll go and fix my time machine, go back to when animals could still speak and then tell MS that they are also going to run Linux on their cloud (duh) and that they should just attach a raw disk... let the OS do the preparation [20:29] lol [20:30] *sigh* [20:30] smoser: I've not had the gce instances trip down the udevadm settle path yet; but I've 20 reboots on the branch just fine [20:30] :) [20:30] ok. lets land taht. [20:31] do you need some time to think on this bug/MP? [20:32] smoser: ok [20:34] i'm landing it. [20:34] i just updated the sl bug with some info (and the ticket) [20:36] k [20:42] smoser: should I make a bionic upload branch then? is everything in master ? [20:47] rharper: smoser: are you happy with switching the 'ignore' behavior on the distro name? If so, I'll make that change in the MP [20:48] paulmey: my preference would be to also check if it wasn't possible; like no kernel module and no tools; [20:48] that woudl be slightly better in case someone rolls their own [21:37] smoser: I've landed your ibmcloud branch, and I've put up a MP for master into ubuntu/devel, https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/344560 [23:00] rharper: is there a good way to check that then? [23:38] rharper: plus, isn't 'mount' the ultimate authority on whether or not it is possible? Available modules should be loaded automatically, correct? [23:39] the current MP tries to mount and only ignores the error when mount says it can't because ntfs is not supported [23:40] what else should I check on top of mount's fstype=auto logic?