[01:02] wow firefox [01:02] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND [01:02] 13751 smoser 20 0 11.566g 8.920g 55180 S 53.8 57.3 195:39.16 firefox [01:06] and then the system locked up. [01:16] Hi, regarding https://bugs.launchpad.net/cloud-init/+bug/1722992 , I was wondering if there was any centos nightly build incorporating a fix I could test? [01:16] Ubuntu bug 1722992 in cloud-init "On the latest centos 7 release, we are unable to resize our instances filesystems" [Medium,Confirmed] [01:26] smoser: the internet with javascript is a terrible place [01:26] im sorry for your loss [01:52] redcavalier: there is a nighlty build on our COPR repo: https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/ [01:53] powersj, yes, ultimately I was asking if it incorporated a tentative fix for that bug or not. [01:53] as far as a fix... quickly reading the bug, I don't see anything completed yet :) [02:08] powersj, thx I'll wait then. [03:34] redcavalier: I got stuck for a couple days on another cc_resizefs module issue that we just landed in master today. I hope to look at that particular bug either tomorrow or the next day. we'll link an inprogress branch to that bug and mark it in progress as we tackle it [03:35] blackboxsw, ah, thanks for the clarification, I'm not familiar how bugs are handled here hence my questions. [03:37] no prob. we should be clear (and I think we are clearing up our process on that a bit too) so yeah when we grab a bug we should mark it "in progress" and attach related branches to it until we can call it fix committed (in master). Once it hits fix committed you'd be able to grab that copr repo mentioned as it builds all the time from master [03:37] I'll definitely ping you here to to celebrate when we get there :) [03:38] in the meantime. thx for your patience (and the pings). [13:42] ckonstanski: I'm not sure how much cloud-init directly deals with udev [13:42] not much I think [13:43] So the eudev thing may not be an issue, at least for cloud-init. [13:43] (I still worry about chef/puppet, but one thing at a time) [13:52] ckonstanski: eudev and udev should be mostly interchangable, it's why we have a virtual/udev [13:54] smoser: ckonstanski is looking to possibly work on the gentoo cloud-init stuff, I believe he has two focuses, updating the gentoo piece to use the new network stack, and support systemd [14:02] smoser: promethianfire: I am filling out the contributor agreement. A project manager is required. Who should I use? [14:04] Done. Got smoser's full name from the launchpad page. [14:21] ckonstanski: right. http://cloudinit.readthedocs.io/en/latest/topics/hacking.html [14:21] you dont need to put an email address. just my name is fine. [14:22] All done [14:26] ckonstanski: thanks. [14:31] This first change is trivial: [14:31] - init_cmd = ['service'] # init scripts [14:31] + init_cmd = ['rc-service'] # init scripts [14:31] [14:31] But now I have to figure out how to test it. Any docs on running in dev? [14:33] ckonstanski: run a 9999 version pointing to your fork I think [14:33] ckonstanski: i'm sorry, but my gentoo knowleged is nil. [14:33] for ubuntu and centos we have scripts in trunk that build a package out of trunk, and i'd be willing to take contributions for gentoo also [14:35] But in the broader sense: the only way to run it is to spin up a VM? No nifty way to put the code through its paces directly on my dev workstation? promethianfire's suggestion (which I do understand) implies that teh VM route is the only way to go. [14:36] I'm not sure about the test harness [14:37] Is there a particular bug that I can test for while spinning up a VM that would fail under the old code and pass if my fix is good? A particular thing I can try in my cloud.cfg? [14:38] atm, no, since both rc-service and services are both still available [14:38] the only thing that'd pick this up are unit tests, if available [14:38] ok [14:39] I did notice that "service" is installed on my laptop and it's provided by openrc. This is going away? [14:43] yes [14:43] eselect news read all [14:43] that [14:43] ckonstanski: well, there are unit tests (run via 'tox') [14:43] but they're just unit tests. [14:43] the last message there mentions it going away [14:43] smoser: yarp [14:44] there are integration tests that run lxc containers, but they dont' run any gentoo [14:44] they could, but there would be some work involved to do that. [14:44] that'd be good [14:45] A packager and lxc. Got it. [14:45] Does tox usually run cleanly? Getting 3 errors out of 5. [14:46] pastebin :P [14:47] smoser: for systemd, I should pass in --init-system=systemd right? [14:47] not sure about this systemd.generators thing :P [14:49] tox failures: https://paste.pound-python.org/show/FkZ6lWLKXJBnUXfVHoSB/ [14:49] prometheanfire: yes. init-system=systemd [14:49] but i think it will default to that. [14:49] Actually that sucked. Let me redirect 2>&1 [14:51] smoser: so, what if I want to install two init systems on the same system? [14:51] the systemd generator turns cloud-init on or off based on if its running in a cloud or not. [14:52] prometheanfire: well, thats up to you. it "should work", in the snese that files can be installed. [14:52] but interaction with the system, i'm not exactly sure of [14:52] on ubuntu up until very recently we did have both upstart and systemd being installed. [14:52] --init-system=systemd,sysvinit [14:52] oh, you can use commas [14:53] I was rerunning setup.py [14:53] For real this time: https://paste.pound-python.org/show/t5M9bUnXhmZBXqRYz1f4/ [14:54] ckonstanski: can you chmod +x files in sysvinit/gentoo/* ? [14:54] as a separate thing [14:54] ckonstanski: well, thats not too bad. its just the ntp tests. limited to one set of tests. basically failing because no support for gentoo [14:55] add to the list [14:55] Need to keep notes. Don't want to do all this in one branch. [14:56] :D [14:57] smoser: rharper: Does the cloud-init failure in the log attached to https://bugs.launchpad.net/cloud-images/+bug/1726818 ring any bells? [14:57] Ubuntu bug 1726818 in cloud-images "vagrant artful64 box filesystem too small" [Undecided,New] [15:01] possibly https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1725067 [15:01] Ubuntu bug 1725067 in cloud-init (Ubuntu Artful) "cloud-init resizefs fails when booting with root=PARTUUID=" [Medium,Fix committed] [15:23] it looks like 17.1 supports python 2.6 to 3.6, is that right? [15:23] prometheanfire: yes [15:27] ok, well 17.1 packaged then [15:43] smoser: https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/332722 [15:49] Odd_Bloke: i responded on that bug. have you recrated this ? [15:53] smoser: I haven't, no; been in meetings all morning. [15:53] Will try now. [16:02] smoser: I can reproduce with 'vagrant init ubuntu/artful64;vagrant up;vagrant ssh'. [17:44] ckonstanski: you submit that? [17:45] should look something like https://git.launchpad.net/~prometheanfire/cloud-init/commit/?id=b1f5be693cbdc857911c9c36080af471ba0b7287 I think [17:47] Odd_Bloke: did you run on "physical" host system ? [17:48] smoser: I did that on my laptop. [17:48] (If that's what you're asking?) [17:48] yeah (versus what i did, running in serverstack guest) [17:48] can you dmesg | pasetbinit [17:48] i have http://paste.ubuntu.com/25811245/ [17:49] yeah, never mind. the bug opener does/did too [17:53] promethianfire: I have not submitted anything yet. The day job calls. Will do it later today unless someone else does it first. [18:01] ckonstanski: I was about to, but I can wait [18:03] Odd_Bloke: i'm done with that bug. from my perspective this surely looks like a kernel issue. [18:03] and i collected logs and such, so i'll leave it there. you can mark /triage the 'cloud-images' task however you would. [18:04] smoser: Ack, thanks. [18:04] kernel traces at 0.000000 seconds into boot [18:05] although mine didnt' stactrace until the resize time frame. [18:26] I was going to create launchpad bugs so I could reference them in my commits. But I'm not seeing how to create a bug in launchpad. I wonder if I have more stuff to set up, like the PGP key. This stuff is what's holding me up from pushing these couple easy changes, and why I need to do it later when I can work through these peripheral issues. Or should I just do the rc-service and chmod +x changes without bugs? [18:27] ckonstanski: if you want to file bugs via email you probably need a pgp key [18:27] if you just want to file a bug in UI.. [18:27] https://bugs.launchpad.net/cloud-init/+filebug [18:28] (that was just https://launchpad.net/cloud-init -> 'Report a bug') [18:30] That helps. I'll at least make the bugs. I have no such link. But I can reach it direcly via the URL. Makes me think my setup is incomplete. Will work on that more later. [18:33] you didnt have a link.. odd. on the right side. [18:33] you're logged in ? [18:33] Logged in yes, link present no. [18:34] Now that I'm on the right page, yes. There's a link. [18:35] my bad [18:35] I can't give it the proper attention right now. Making mistakes. [18:47] :) [21:51] smoser: I nominated the following for xenial/zesty/artful https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1724951 not sure if I can actually add the series bug task myself [21:51] Ubuntu bug 1724951 in cloud-init "Ntp schema definition permits empty ntp cloud-config, but code disallows" [Medium,In progress] [21:57] blackboxsw: approved [21:59] ahh thanks powersj [22:36] ckonstanski: once you get a branch pushed with your changes showing up in launchpad it's a button push to submit