=== rangerpbzzzz is now known as rangerpb [15:59] rharper, fyi, shadowusers really sucks. [15:59] s/shadowusers/extrausers/ [15:59] http://pad.lv/1679765 [16:00] bug 1679777 [16:00] bug 1679765 [16:00] i thought i had amup here. [16:15] the first bug is a coreutils issue; I believe the --extrausers was introduced in some of those tools; I guess not all of them [16:15] the second issue is related to cloud-init's concept of 'system-user'; that does need to be addressed; [16:16] generally agree. [16:16] the first bug is just a half-done implementation [16:16] but so is the second. [16:17] there are well defined ways that you can iterate users or get information about users. [16:17] python uses such ways [16:17] and they dont work with 'extrausers' [16:18] it may end up being the same bug 'incomplete extrausers implementation' [16:18] I suspect it's broken without cloud-init; ie, if you snap create-user with an assertion, the same issues remain w.r.t user manipulation/configuration/enumeration [16:19] we should likely sync with foundations [16:21] well, yes. cloud-init *does* have the ability to know that for users it created. [16:21] but "what is the home directory for bob". should not require "is bob an extra user?" [16:31] correct, which to me is a bug in the getent failure; I think if --extrausers is available in the tools, the the default search should try both paths (/etc/passwd , /var/lib/extrausers/passwd) [16:31] etc [17:40] smoser hey, for the reporting stuff in cloud-init, what's a common usage of it? [17:41] to do the bidding of harlowja [17:41] some folks at godaddy are trying to gather more insight into how long modules in cloud-init run for and ... [17:41] but it was added for maas [17:41] and this reporting stuff looks designed for doing that (sort of) [17:41] maas wanted status [17:41] ya, makes sense [17:42] sounds similar [17:42] but yeah. the reporting stuff is doing that too [17:42] cool beans [17:42] and rharper has stuff that reads a journal [17:42] ? [17:42] out loud? [17:42] and timestpams things [17:42] cool cool [17:42] it reads harlowja's journal [17:42] my diaryyyyy [17:42] noooo [17:42] "Dear diary, today I met a new friend" [17:42] his name was bob [17:42] "I think i love cloud-init" [17:42] lol [17:43] the things i write about smoser ... [17:43] don't read those [17:43] lol [17:43] rharper, where do we see cloud-init annotate ? [17:43] https://lists.ubuntu.com/archives/ubuntu-server/2016-October/007419.html [17:43] https://code.launchpad.net/~raharper/+git/cloudinit-analyze [17:44] hmmm [17:45] interesting [17:45] cool, thx [17:45] forwarding some of htis [17:45] also, it'd be highly useful if we wrapped each subp with a reporting event [17:45] not the journal entries i hope [17:45] that'd give us per exec data [17:45] smoser: lol [17:45] whats this 'ubuntu-server' ml [17:45] :-P [17:48] I also sent it to the cloud-init ML [17:48] which is hosted on launchpad [17:48] oh [17:48] * harlowja shuts up now [17:48] lol [18:07] hi [18:07] can someone help me debug a timeout [18:07] please [18:07] https://paste.fedoraproject.org/paste/VifD~R6n8t78gj-m-Iv4CV5M1UNdIGYhyRLivL9gydE= [18:09] erick3k, at very least you'll need to paste /var/log/cloud-init.log and also journalctl output [18:09] ty [18:12] https://paste.fedoraproject.org/paste/7rV6y2UBLmcJ77KPWP4PjF5M1UNdIGYhyRLivL9gydE=/raw [18:12] that is /var/log/cloud-init.log (although there is nothing other than a warning that config drive was unplugged) [18:13] and journalctl output says invalid argument === rangerpb is now known as rangerpbzzzz [22:26] can someone help me when get a change, https://paste.fedoraproject.org/paste/6-WoDBw8~Pw9QtOd2KV~lF5M1UNdIGYhyRLivL9gydE= [22:26] getting big timeouts [22:32] erick3k: which line? [22:33] nacc i dont really care about the warnings if they are not causing the timeout nor i care it can't print to the console but i am guessing this is the big timeout [22:33] Cloud-init v. 0.7.5 finished at Thu, 06 Apr 2017 22:16:28 +0000. Datasource DataSourceConfigDrive [local,ver=2][source=/dev/sr1]. Up 311.33 seconds [22:33] that is 5 mins [22:33] i guess? [22:34] are these from multiple installs? why is cloud-init 'finished' more than once [22:35] also it's a bit odd that the timezone appears to jump in the logs? [22:35] 2017-04-06 18:16:28,208 [22:35] Thu, 06 Apr 2017 22:16:28 +0000. [22:35] lines 120 and 121 [22:35] ummm maybe i didn't clear the log [22:36] yes its weird and i can't find why those huge timeouts [22:36] starts at Thu, 06 Apr 2017 22:11:22 [22:36] like the vm takes after is up, like 20 mins before it reboots (runcmd) [22:36] ends at Thu, 06 Apr 2017 22:16:28 +0000 [22:37] erick3k: which log is this? [22:37] 2017-04-06 18:11:26,935 - cloud-init[WARNING]: Stdout, stderr changing to (>> /var/log/cloud-init-output.log, >> /var/log/cloud-init-output.log) [22:37] yes [22:37] Cloud-init v. 0.7.5 running 'init' at Thu, 06 Apr 2017 22:16:21 +0000. Up 305.12 seconds. [22:37] there is the 5 minute gap [22:37] changes cloud-init.log to cloud-init-output.log [22:37] (i think) [22:37] not sure why, am using centos 7 cloud image [22:38] and why that gap? how can i tune that timeout thingy [22:39] any ideas nacc? [22:40] erick3k: so that output is from cloud-init.log, erick3k ? [22:40] there is nothing on cloud-init.log [22:40] erick3k: i'm not sure why you think it's a timeout? [22:41] well what could it be doing for 15 minutes? [22:41] erick3k: there is a delay, but that doesn't necessarily equate to a timeout, unless you have some other data? [22:41] 5 minutes, i thought? [22:41] na [22:41] once the machine is up and ready for login [22:41] last command in runcmd: -reboot is run like 15 - 20 minutes later [22:42] erick3k: but i can only go off what's in the logs [22:43] erick3k: you might need smoser or rharper for this [22:43] yes he tried but busy [22:43] thats all there is on logs, cloud-init.log is changed to cloud-init-output.log [22:43] so is same file [22:43] erick3k: https://lists.ubuntu.com/archives/ubuntu-server/2016-October/007419.html [22:44] erick3k: i wonder if that profiler would help [22:45] he saying 13% improvement [22:45] erick3k: by making changes based upon profiling [22:45] erick3k: my point was the profiler might tell you where all your time is being spent, if it's cloud-init [22:45] i have the machines in raid 0 with two NVME intel latest pci ssd, so you can imagine how fast things are [22:46] it boots in like 3 seconds so 15 minutes is just beyond ridiculous amount of time to have an instance ready [22:47] you think it could be a timeout on the os? [22:47] *OS [22:47] erick3k: i really don't know -- was hoping it'd be something obvious, but i don't know enough about cloud-init or cento [22:47] *centos [22:48] kind of same happens in ubuntu 14 [22:48] takes a long time [22:48] now that you tell me might be OS timeout for network gonna check that first [22:49] is there a way to have the network not even look for dhcp while turning on until cloudinit injects the network? [22:49] erick3k: i assumethat would be centos specific [22:50] all [22:50] ubuntu / centos [22:50] i seal the vm with this in interfaces [22:51] DEVICE=eth0 [22:51] TYPE=Ethernet [22:51] BOOTPROTO=dhcp [22:51] ONBOOT=yes [22:51] what if i delete that? [22:51] can cloud-init still inject? [23:13] YES SR [23:13] THAT WAS THE TIMEOUT [23:13] FINALLY [23:13] hehe [23:14] now instance ready in 6 seconds [23:14] thats how its done :)