[00:00] <rharper> it defaults to user fedora  (versus say centos); not sure what the default for the centos6 AMI was
[00:41] <powersj> rharper: thx for review that is exactly what I was looking for :)
[00:46] <rharper> cool
[13:13] <smoser> rharper, ping
[13:14] <smoser> would this be expected to render functional networking ?
[13:14] <smoser>  http://paste.ubuntu.com/24748335/
[13:40] <rharper> smoser: reading
[13:41] <rharper> 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
[13:43] <rharper> smoser:  this is what curtin renders as eni with that:  http://paste.ubuntu.com/24748563/
[13:51] <smoser> bah
[13:51] <smoser> http://paste.ubuntu.com/24748651/
[13:52] <smoser> i ended up figuring it out.
[14:12] <smoser> wow.
[14:12] <smoser> so that was a large time sync, but ended up verifying this actually works. so thats nice.
[14:17] <rharper> oh, if I read that right;' that's nasty;  the vlan got the ens3 name because of the duplicate macs
[14:17] <smoser> yeah
[14:17] <dpb1> where did duplicate macs come from?  random?
[14:17] <smoser> the .link file that i left around
[14:17] <smoser> it renamed the newly created vlan device
[14:17] <smoser> and then vlan was like WTH!
[14:18] <smoser> rharper, i'm not sure why udev doesn't do this for us
[14:18] <rharper> what should udev do for us ?
[14:18] <smoser> ie, we say DRIVERS=="?*"
[14:19] <smoser> why doesn't udev see the newly created vlan device
[14:19] <smoser> and rename it
[14:19] <rharper> the vlan isn't going to generate a udev event
[14:19] <smoser> (that would be bad... but what prevents it)
[14:19] <smoser> then why did systemd.link do it?
[14:19] <rharper> at least, I don't think it would but I'm not sure
[14:19] <rharper> we create a vlan dev *with* the name eth0.101
[14:19] <rharper> there's not rename event to occur
[14:20] <smoser> right
[14:20] <rharper> s/not/no
[14:20] <smoser> with a name eth0.101 and a mac that matches that of eth0
[14:20] <smoser> maybe udev just fails to rename it
[14:20] <smoser> what i'm asking is...
[14:21] <rharper> 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] <smoser> a.) system boots, ethernet device is present, udev hotplug... that gets named 'eth0'
[14:21] <smoser> per
[14:21] <smoser>  SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="fa:16:3e:4b:63:49", NAME="eth0"
[14:21] <smoser> b.) vlan device is created that has a name eth0.101
[14:21] <smoser> but has the mac "fa:16:3e:4b:63:49"
[14:22] <smoser> in my buggy scenario a .link file renamed eth0.101 to 'ens3'
[14:22] <smoser> but why wouldn't udev *attempt* to rename eth0.101 to eth0 ?
[14:22] <rharper> 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] <rharper> what was the rename value in sysfs ?
[14:23] <smoser> what is the field ?
[14:23] <smoser> i had collected grep -r . ens3/
[14:23] <smoser> (see the paste)
[14:26] <rharper> looking
[14:26] <blackboxsw> morning
[14:26] <rharper> ens3/name_assign_type:4
[14:27]  * rharper googles 
[14:28] <rharper> https://patchwork.kernel.org/patch/4526491/
[14:34] <rharper> 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] <rharper> now that we remove it, we don't get a second rename of devices with matching mac addresses
[14:35] <rharper> 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] <rharper> possibly reading the driver of the interface and including that in the [Match] section
[15:18] <smoser> powersj, the other hting i have today... the daily builds from recipe started faling yesterday
[15:18] <smoser> because some of the patches in need updating
[15:18] <smoser> (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)
[15:42] <rharper> 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] <smoser> thats possible.
[15:43] <smoser> if he wasnt cleaning them.
[15:43] <smoser> but cloud-init *would* clean them.
[15:43] <dgarstang> Well it sucks I can't use cloud-init. :(
[15:43] <smoser> (which ... unfortunately now it will not...so ones that it wrote before it wont clean on upgrade)
[15:43] <smoser> dgarstang, we'll get you there.
[15:44] <smoser> dgarstang, if you want... and you have an instance that i can ssh into, with trunk rpm... i could poke a bit
[15:44] <dgarstang> smoser: Thanks, appreciate it, but for the time being I'll just have to do it with scripts executed from cloud-init
[15:44] <rharper> 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] <dgarstang> I don't really know how to categorise the issue exactly
[15:44] <rharper> no need to , just say "disk setup and mounts not working on centos6 ami on ec2"
[15:45] <rharper> dump in your user-data you gisted and that should be all we need
[15:45] <smoser> including the ami id that you used woudl be good.
[15:45] <smoser> or if it was a custom one...reproducing with a "official" of some sort
[15:46] <dgarstang> Gonna retry it first with a fresh pair of eyes
[16:16] <dgarstang> 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] <dgarstang> scrap that. USer error
[18:38] <blackboxsw> 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] <blackboxsw> or should we make sure the python-jsonschema dep is called out for the build env.
[18:43] <blackboxsw> yep, it's also the same issue w/ powersj's https://bugs.launchpad.net/cloud-init/+bug/1695318
[18:44] <blackboxsw> ok right, grabbed it.
[18:45] <smoser> blackboxsw, yes we should skip i think
[18:45] <smoser> blackboxsw, did you click the checkymark on 1692087 or did i
[18:46] <smoser> oh. i see in the log that you did.
[18:47] <blackboxsw> oops smoser, I just finished 2093. I think I fat-fingered 2087
[18:47] <blackboxsw> was thinking of relying on a quick azure deployment test in 2093's case. /me is setting up my own account
[18:49] <smoser> 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] <smoser> (i was launching ones in serverstack and using /dev/vdb)
[18:51] <blackboxsw> smoser: like https://bugs.launchpad.net/cloud-init/+bug/1695318 maybe
[18:51] <blackboxsw> oops I mean..
[18:51] <blackboxsw> #1634678
[18:51] <blackboxsw> smoser: like https://bugs.launchpad.net/cloud-init/+bug/1634678
[18:52] <smoser> blackboxsw, so we think we're done with sru templates ?
[18:53] <blackboxsw> I'm checking again. you did the lion's share thx
[18:54] <blackboxsw> smoser: yes looks done
[18:57] <smoser> none on bug 1692087
[18:57] <smoser> i think
[18:57] <smoser> i'll do that one.
[19:27] <shaharmor> Hello, anyone around?
[19:28] <smoser> hey
[19:29] <shaharmor> Hey @smoser
[19:30] <shaharmor> I'm having some trouble with cloud-init getting stuck before finishing the module:config part
[19:30] <shaharmor> I opened this bug: https://bugs.launchpad.net/cloud-init/+bug/1694399
[19:31] <shaharmor> I'm able to replicate it every few instances I start
[19:31] <shaharmor> I'm wondering if its something wrong specifically in my machine or a general thing
[19:31] <shaharmor> because I believe cloud-init is something that is used extensively
[19:32] <smoser> shaharmor, cloud-final.conf runs that
[19:32] <smoser> and runs
[19:32] <smoser> start on (stopped rc RUNLEVEL=[2345] and stopped cloud-config)
[19:32] <smoser> (per /etc/init/cloud-final.conf)
[19:33] <smoser> i suspect cloud-config has stopped , as it clearly ran. i doubt its hung there.
[19:33] <shaharmor> yeah I'm not sure its hung
[19:33] <smoser> but something on your system is preventing 'rc' from finishing
[19:33] <shaharmor> But the thing is that its not always happening
[19:34] <smoser> this is an official ubuntu image ?
[19:34] <shaharmor> It was started from the official one (On AWS), and some stuff added on it
[19:35] <shaharmor> then an AMI is created
[19:35] <shaharmor> and when that AMI is used with "userdata", this happens occasionally
[19:36] <smoser> 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] <smoser> shaharmor, can you run 'initctl list'
[19:37] <shaharmor> Thats what I though
[19:37] <shaharmor> Let me try to replicate it again because I already shut down that machine
[20:03] <shaharmor> @smoser ok I managed to reproduce
[20:03] <shaharmor> running it now
[20:04] <shaharmor> output of 'initctl list': https://pastebin.com/7i3Wq3MQ
[20:09] <shaharmor> this is the command that runs the init.d scripts? /bin/sh /etc/init.d/rc 2
[20:09] <shaharmor> could it be that its still running other scripts in init rc2 and just waits for them to qui?
[20:17] <shaharmor> ok I figured it out
[20:19] <shaharmor> I had another script (not related to the userdata) that was set to run on rc2 that was stuck
[20:19] <shaharmor> when I killed it, the module:final ran
[20:33] <smoser> blackboxsw, you're working https://bugs.launchpad.net/cloud-init/+bug/1695318
[20:33] <smoser> right ?
[20:33] <blackboxsw> almost done smoser
[20:33] <blackboxsw> yep
[20:33] <smoser> and i'll need that to get the xenial, yakkety, zesty dailiy archive builds
[20:34] <blackboxsw> was adding a card for that
[20:34] <smoser> i think those will just start workign again ocne we merge your fix to trunk
[20:34] <smoser> ie:
[20:35] <smoser>  https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-yakkety
[20:35] <smoser>  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] <blackboxsw> pushing a branch for review
[20:47] <blackboxsw> smoser: powersj https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/325024
[20:48] <smoser> blackboxsw, love it
[20:49] <blackboxsw> let's just hope that handles it. I'm trying to get my cent6 lxd up again
[20:49] <blackboxsw> It should have covered all the atttached unit test failure in the bug. Just not sure if there are more now.
[20:50] <smoser> just queued a build at https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-xenial
[20:51] <smoser> and https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-devel
[20:51] <smoser> fingers crossed
[20:51] <smoser> and i have to run
[21:00] <blackboxsw> thx smoser
[21:02] <blackboxsw> 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] <powersj> blackboxsw: I assume you are referring to the centos tests?
[21:02] <powersj> I am re-writting those right now
[21:02] <blackboxsw> https://git.launchpad.net/server-team-ci/scripts/centos/centos-run.sh rather
[21:03] <blackboxsw> right, if you are touching it I'll be hands off
[21:03] <powersj> https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/324982
[21:03] <blackboxsw> reviewing
[21:03] <powersj> I'm extending it so we can make it part of the pipeline
[21:03] <blackboxsw> ++
[21:04] <powersj> have all these nice tests, now time to run them on every merge proposal rather than daily :D
[21:04] <blackboxsw> heh
[21:04] <blackboxsw> man, I'd really love to use python instead of bash for any new scripts we write
[21:05] <blackboxsw> but, that's just because my shell chops are el-stinko
[21:05] <blackboxsw> and bash is hard to test.
[21:05] <blackboxsw> was just referring to the newscript comment from smoser on your branch
[21:07] <powersj> I hear you; I switch between both
[21:07] <powersj> the proposed automation is in python so far, but rest will be shell
[21:09] <blackboxsw> yeah so many external calls 'lxc ... ' it lends itself more easily to shell scripts. but, yeah.
[21:52] <blackboxsw> yay green, thx powersj smoser https://jenkins.ubuntu.com/server/view/Cloud-init/job/cloud-init-centos-6/21/
[21:52] <powersj> awesome
[21:53] <blackboxsw> 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] <powersj> sweet
[21:53] <blackboxsw> it won't be until Monday though, so it probably won't help your existing branch.
[21:53] <blackboxsw> it won't be reviewed/landed