[00:00] it defaults to user fedora (versus say centos); not sure what the default for the centos6 AMI was [00:41] rharper: thx for review that is exactly what I was looking for :) [00:46] cool === sambetts|afk is now known as sambetts [13:13] rharper, ping [13:14] would this be expected to render functional networking ? [13:14] http://paste.ubuntu.com/24748335/ [13:40] smoser: reading [13:41] first glance looks sane; I generally run it through curtin apply_net or cloud-init net_convert and see what the eni ends up looking like === rangerpbzzzz is now known as rangerpb [13:43] smoser: this is what curtin renders as eni with that: http://paste.ubuntu.com/24748563/ [13:51] bah [13:51] http://paste.ubuntu.com/24748651/ [13:52] i ended up figuring it out. [14:12] wow. [14:12] so that was a large time sync, but ended up verifying this actually works. so thats nice. [14:17] oh, if I read that right;' that's nasty; the vlan got the ens3 name because of the duplicate macs [14:17] yeah [14:17] where did duplicate macs come from? random? [14:17] the .link file that i left around [14:17] it renamed the newly created vlan device [14:17] and then vlan was like WTH! [14:18] rharper, i'm not sure why udev doesn't do this for us [14:18] what should udev do for us ? [14:18] ie, we say DRIVERS=="?*" [14:19] why doesn't udev see the newly created vlan device [14:19] and rename it [14:19] the vlan isn't going to generate a udev event [14:19] (that would be bad... but what prevents it) [14:19] then why did systemd.link do it? [14:19] at least, I don't think it would but I'm not sure [14:19] we create a vlan dev *with* the name eth0.101 [14:19] there's not rename event to occur [14:20] right [14:20] s/not/no [14:20] with a name eth0.101 and a mac that matches that of eth0 [14:20] maybe udev just fails to rename it [14:20] what i'm asking is... [14:21] well, I guess I'm saying, I wouldn't expect udev to rename unless it saw an event for a device; and there's no need to do a rename because it's already at the name we expect [14:21] a.) system boots, ethernet device is present, udev hotplug... that gets named 'eth0' [14:21] per [14:21] SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="fa:16:3e:4b:63:49", NAME="eth0" [14:21] b.) vlan device is created that has a name eth0.101 [14:21] but has the mac "fa:16:3e:4b:63:49" [14:22] in my buggy scenario a .link file renamed eth0.101 to 'ens3' [14:22] but why wouldn't udev *attempt* to rename eth0.101 to eth0 ? [14:22] that's a good question w.r.t eth0.101 getting renamed by systemd; I would have thought that the device type would have prevented it from getting renamed [14:22] what was the rename value in sysfs ? [14:23] what is the field ? [14:23] i had collected grep -r . ens3/ [14:23] (see the paste) [14:26] looking [14:26] morning [14:26] ens3/name_assign_type:4 [14:27] * rharper googles [14:28] https://patchwork.kernel.org/patch/4526491/ [14:34] I think the link file we wrote is not strict enought; the vlan matched by mac only; we don't have the DRIVERS=?* equivalent which was meant to ignore "virtual" network devices [14:34] now that we remove it, we don't get a second rename of devices with matching mac addresses [14:35] alternatively we would need to ensure the .link files included something in-addition to the mac address to prevent it from matching on non-physical devices [14:35] possibly reading the driver of the interface and including that in the [Match] section [15:18] powersj, the other hting i have today... the daily builds from recipe started faling yesterday [15:18] because some of the patches in need updating [15:18] (ubuntu/xenial and ubunty/yakkety have patches ... to the azure ds and blackboxsw's' changes there caused us to need to refresh them.. easy, just hae to do it) === sambetts is now known as sambetts|afk [15:42] smoser: you know, (see above for the .link trouble we had with vlans and bonds I suspect); I wonder if much of that trouble xnox had was related to those .link files matching on the virtual devices as well [15:43] thats possible. [15:43] if he wasnt cleaning them. [15:43] but cloud-init *would* clean them. [15:43] Well it sucks I can't use cloud-init. :( [15:43] (which ... unfortunately now it will not...so ones that it wrote before it wont clean on upgrade) [15:43] dgarstang, we'll get you there. [15:44] dgarstang, if you want... and you have an instance that i can ssh into, with trunk rpm... i could poke a bit [15:44] smoser: Thanks, appreciate it, but for the time being I'll just have to do it with scripts executed from cloud-init [15:44] dgarstang: did we file a bug yet with your issue? I'd like to get one so we can track it; we'll be doing more with centos and updated cloud-init and certainly want to get your issue resolved [15:44] I don't really know how to categorise the issue exactly [15:44] no need to , just say "disk setup and mounts not working on centos6 ami on ec2" [15:45] dump in your user-data you gisted and that should be all we need [15:45] including the ami id that you used woudl be good. [15:45] or if it was a custom one...reproducing with a "official" of some sort [15:46] Gonna retry it first with a fresh pair of eyes [16:16] So, I just tried this again, I see this in the output ... "mkfs.ext2: option requires an argument -- 't'" and "Usage: mkfs.ext2 [-c|-l filename] [-b block-size] [-C cluster-size]"... I don't know why since I told it to use ext4 [16:16] scrap that. USer error [18:38] smoser: I need to fix this right ? https://launchpadlibrarian.net/322019862/buildlog_ubuntu-zesty-amd64.cloud-init_0.7.9-1538-g0a448dd-0ubuntu1+1438~trunk~ubuntu17.04.1_BUILDING.txt.gz As in we should skip unit tests around json schema if the dependency isn't present right? [18:39] or should we make sure the python-jsonschema dep is called out for the build env. [18:43] yep, it's also the same issue w/ powersj's https://bugs.launchpad.net/cloud-init/+bug/1695318 [18:43] Ubuntu bug 1695318 in cloud-init "centos 6/7 schema unittests failing" [Undecided,In progress] [18:44] ok right, grabbed it. [18:45] blackboxsw, yes we should skip i think [18:45] blackboxsw, did you click the checkymark on 1692087 or did i [18:46] oh. i see in the log that you did. [18:47] oops smoser, I just finished 2093. I think I fat-fingered 2087 [18:47] was thinking of relying on a quick azure deployment test in 2093's case. /me is setting up my own account [18:49] blackboxsw, for that bug, https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bugs/lp-1686514/disk-setup can help format a device to look like ntfs and/or gpt [18:49] (i was launching ones in serverstack and using /dev/vdb) [18:51] smoser: like https://bugs.launchpad.net/cloud-init/+bug/1695318 maybe [18:51] Ubuntu bug 1695318 in cloud-init "centos 6/7 schema unittests failing" [Undecided,In progress] [18:51] oops I mean.. [18:51] #1634678 [18:51] smoser: like https://bugs.launchpad.net/cloud-init/+bug/1634678 [18:52] Ubuntu bug 1634678 in cloud-init (Ubuntu Trusty) "fs_setup always creates new filesystem with partition 'auto'" [Low,Confirmed] [18:52] blackboxsw, so we think we're done with sru templates ? [18:53] I'm checking again. you did the lion's share thx [18:54] smoser: yes looks done [18:57] none on bug 1692087 [18:57] bug 1692087 in cloud-init (Ubuntu Zesty) "check_partition_layout has false positives when partitioned with gpt" [Medium,Confirmed] https://launchpad.net/bugs/1692087 [18:57] i think [18:57] i'll do that one. [19:27] Hello, anyone around? [19:28] hey [19:29] Hey @smoser [19:30] I'm having some trouble with cloud-init getting stuck before finishing the module:config part [19:30] I opened this bug: https://bugs.launchpad.net/cloud-init/+bug/1694399 [19:30] Ubuntu bug 1694399 in cloud-init "module:config isn't finishing, stuck after locale configuration" [Undecided,New] [19:31] I'm able to replicate it every few instances I start [19:31] I'm wondering if its something wrong specifically in my machine or a general thing [19:31] because I believe cloud-init is something that is used extensively [19:32] shaharmor, cloud-final.conf runs that [19:32] and runs [19:32] start on (stopped rc RUNLEVEL=[2345] and stopped cloud-config) [19:32] (per /etc/init/cloud-final.conf) [19:33] i suspect cloud-config has stopped , as it clearly ran. i doubt its hung there. [19:33] yeah I'm not sure its hung [19:33] but something on your system is preventing 'rc' from finishing [19:33] But the thing is that its not always happening [19:34] this is an official ubuntu image ? [19:34] It was started from the official one (On AWS), and some stuff added on it [19:35] then an AMI is created [19:35] and when that AMI is used with "userdata", this happens occasionally [19:36] its been a long time. i can tell you that its very unlikely that there is a general bug like you're describing [19:37] shaharmor, can you run 'initctl list' [19:37] Thats what I though [19:37] Let me try to replicate it again because I already shut down that machine === nacc_ is now known as ancc === ancc is now known as nacc [20:03] @smoser ok I managed to reproduce [20:03] running it now [20:04] output of 'initctl list': https://pastebin.com/7i3Wq3MQ [20:09] this is the command that runs the init.d scripts? /bin/sh /etc/init.d/rc 2 [20:09] could it be that its still running other scripts in init rc2 and just waits for them to qui? [20:17] ok I figured it out [20:19] I had another script (not related to the userdata) that was set to run on rc2 that was stuck [20:19] when I killed it, the module:final ran [20:33] blackboxsw, you're working https://bugs.launchpad.net/cloud-init/+bug/1695318 [20:33] right ? [20:33] Ubuntu bug 1695318 in cloud-init "centos 6/7 schema unittests failing" [Undecided,In progress] [20:33] almost done smoser [20:33] yep [20:33] and i'll need that to get the xenial, yakkety, zesty dailiy archive builds [20:34] was adding a card for that [20:34] i think those will just start workign again ocne we merge your fix to trunk [20:34] ie: [20:35] https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-yakkety [20:35] https://launchpadlibrarian.net/322160649/buildlog_ubuntu-yakkety-amd64.cloud-init_0.7.9-1541-g1cd4323-0ubuntu1+1385~trunk~ubuntu16.10.1_BUILDING.txt.gz [20:36] pushing a branch for review [20:47] smoser: powersj https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/325024 [20:48] blackboxsw, love it [20:49] let's just hope that handles it. I'm trying to get my cent6 lxd up again [20:49] It should have covered all the atttached unit test failure in the bug. Just not sure if there are more now. [20:50] just queued a build at https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-xenial [20:51] and https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-devel [20:51] fingers crossed [20:51] and i have to run [21:00] thx smoser [21:02] powersj: I'm extending to https://git.launchpad.net/server-team-ci/ allow passing in parameters like WIP branch URL so that it can work with more than just cloud-init/master [21:02] blackboxsw: I assume you are referring to the centos tests? [21:02] I am re-writting those right now [21:02] https://git.launchpad.net/server-team-ci/scripts/centos/centos-run.sh rather [21:03] right, if you are touching it I'll be hands off [21:03] https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/324982 [21:03] reviewing [21:03] I'm extending it so we can make it part of the pipeline [21:03] ++ [21:04] have all these nice tests, now time to run them on every merge proposal rather than daily :D [21:04] heh [21:04] man, I'd really love to use python instead of bash for any new scripts we write [21:05] but, that's just because my shell chops are el-stinko [21:05] and bash is hard to test. [21:05] was just referring to the newscript comment from smoser on your branch [21:07] I hear you; I switch between both [21:07] the proposed automation is in python so far, but rest will be shell [21:09] yeah so many external calls 'lxc ... ' it lends itself more easily to shell scripts. but, yeah. [21:52] yay green, thx powersj smoser https://jenkins.ubuntu.com/server/view/Cloud-init/job/cloud-init-centos-6/21/ [21:52] awesome [21:53] powersj: per the other comment you got on your branch about not dup'ing the dependencies, I'll get a make ci-deps Makefile target to you. I'm trying to test out something right now [21:53] sweet [21:53] it won't be until Monday though, so it probably won't help your existing branch. [21:53] it won't be reviewed/landed === rangerpb is now known as rangerpbzzzz === Hazelesque_ is now known as Hazelesque