[00:08] Goneri: ifconfig_vtnet0=dhcp was already there before cloud-init touched it. I'm talking about the defaultrouter line! [00:09] meena, there is probably a name=eth0 in the metadata that force the renaming, so line 12 and 13 are ok [00:09] and so far, the provider does not clean up the previous lines from the /etc/rc.conf, should it? [00:10] ah nice defaultrouter [00:12] re cleanup: nah [00:12] * meena sleep now === tds9 is now known as tds [01:13] thanks you rharper and Odd_Bloke for the reviews, I think I've addressed all of them. I'm regenerating new images. === tds2 is now known as tds [08:08] https://github.com/canonical/cloud-init/pull/61#discussion_r359656257 hell no. [08:39] o/ [10:28] wyoung: Heya [10:58] Hey meena ! How's stuff and / or junk? [11:19] Hi cloud-init team, is there any centos cloud image with cloud-init-18.5? [11:23] meena, Hi [11:41] mkrai__: why so specific? [11:42] meena, Hi, I am facing issue on centos 7.6 with cloud-init [11:42] network is not configured [11:45] the cloud-init configures the wrong interface [11:51] meena, ^ [11:52] mkrai__: which cloud? how exactly is it configured wrong? [11:52] meena, [11:52] meena OpenStack [11:54] mkrai__: what do the logs say? [11:54] meena, I have 3 interfaces on the node, 2 ethernet(enps0f0 and enps0f1) and 1 HFI(ib0). Openstack tries to boot interface on enps0f1 but cloud-init does on enps0f0 [11:55] meena, http://paste.openstack.org/show/787707/ [12:37] mkrai__: and paste cloud-init query --all [12:39] that was supposed to be expressed less urgent and more friendly, but, phone swipe [12:41] meena, http://paste.openstack.org/show/787784/ [12:57] mkrai__: as root or with sudo ;) [12:57] wait that is [12:58] weird [12:58] meena, with sudo [13:03] mkrai__: yeah, sorry, what i mean is, the result is weird [13:04] meena, yeah, that seems weird to me to ;) [13:05] mkrai__: can you curl the metadata URL? [13:05] meena network is not configured so I can't [13:06] https://docs.openstack.org/nova/latest/admin/metadata-service.html [13:06] well, yeah, that makes sense [13:09] i just admit I've never setup a three interface computer with cloud-init, we'd usually only setup one interface, and do the rest with puppet [13:18] I'm trying to wrap my head around how to leverage packer and cloud-init to automate creation of golden AMIs. there are some actions that need to take place while the given AMI is being baked, and there are some that will happen on each boot of an instance using that AMI [13:19] with that in mind for the actions that need to take place on each boot, should I be placing cloud-init stuff in /var/lib/cloud/scripts/per-boot, or should I tack onto /etc/cloud/cloud.cfg.d/ ? [13:20] my source will be various linux distros sanctioned by their vendors, such as ubuntu/centos/etc, so they already have cloud-init in their AMIs [13:33] ananke: unless Packer provides a metadata service, https://cloudinit.readthedocs.io/en/latest/topics/datasources.html you'd wanna stick with a script [13:34] ananke: cloud-init should only run on the first boot on your AMI, to fix the partition and fs sizes and setup network and hostname [13:36] meena: packer utilizes ec2 metadata server to seed it the initial user data. these will be golden AMIs that will receive additional setup when they become instances [13:37] ananke: cool cool cool [13:37] seeing as cloud-init is supposed to provide all of the above functionality, per-instance, per-boot, per-once, etc - I'm wondering what is the appropriate location I should be leveraging. it seems that these days cloud-init is baked into most major AMIs [13:57] I'm just a firm believer in idempotency, and puppet [13:59] what with being Co-founder of voxpupuli and all [14:54] ananke: The /var/lib/cloud/scripts/per-* paths sound like what you want, I think. [14:54] meena: cloud-init runs on every boot, but a lot of what it does only happens on first boot. [15:21] Odd_Bloke: meena thanks for the reviews. I updated my branch with the fixes. Also, I force pushed a commit to remove an automatic non-ff merge from master (ugh, sorry), shouldn't be a problem, though. [15:22] Odd_Bloke: that does not change my preference towards systems that are made to be idempotent. [15:36] meena: Sure, but "cloud-init should only run on the first boot on your AMI" does not describe cloud-init's default behaviour, nor its behaviour in any distros I'm aware of. :p [15:36] (If you want to install Ruby on your systems, that's your business. ;) [15:37] Ruby is one of the best debuggable systems i know, so yes, i love working with it [15:38] hit me up, as soon as python has something close in comfort and power to pry and pry-byebug [15:40] meena: ipdb? [15:46] Odd_Bloke: how do i show the source code of a thing in ipdb? [15:48] meena, if you are at a break point type 'l' [15:52] meena: `l` will show you your current source code context, is that what you meant? [15:55] Odd_Bloke: nah, more like show me the implementation of x [15:56] So in IPython you can do foo?? and it will display that. `ipdb` gives me a SyntaxError if I try to do that, so maybe it isn't possible. [16:01] meena: Aha, `psource`. [16:53] Odd_Bloke, portdirect smoser meena https://bugs.launchpad.net/cloud-init/+bug/1857031 whenever you've time. Thanks! [16:53] Ubuntu bug 1857031 in OpenStack Compute (nova) "cloud-init configures wrong interface when trying to configure two interfaces with OpenStack cloud" [Undecided,New] [16:56] mkrai__: can you please run "cloud-init query --all" on that machine and attach the content to the bug? I'd particularly like to see the contenst of network_json that is reported there [16:56] bah missed it, I'll add it to the bug [16:56] he's gone [16:56] yeah followup up on the bug :/ [16:56] look for WARN [16:56] thats the issue [16:56] centos 7 . [16:57] ahh thanks, just did a quick driveby and hadn't caught up on backlog [16:57] and looks like the submitter also attached a paste of network data .json already to the bug anyway too [16:58] its a dupe of https://bugs.launchpad.net/cloud-init/+bug/1801364 [16:58] Ubuntu bug 1801364 in cloud-init "persisting OpenStack metadata fails" [Undecided,Fix committed] [16:58] ahh right, yeah [16:58] you nailed that symptom/fix, but that shouldn't have affected which network device got chosen I would think. but looking a bit more into it [16:59] well, it fails during local [16:59] so it just tries the fallback/dhcp [17:00] and interesting is that the 'fix' was released in 18.5 I think and logs are from 19.2 cloud-init [17:01] ohhh 18.2 [17:01] not 19.2 [17:01] my mind was playing tricks on me [17:01] i'm not certain ther are not other issues at play [17:01] there may well be. [17:02] but if it doesn't persist the data then we're down a sour path [17:06] Odd_Bloke: thanks! [17:49] thx for the triage on that bug smoser. yes on the instance-data.json being a sour path. Yet, the perist_instance_data happens after _get_data was already run successfully or otherwise. So, I *think* we just don't get the instance-data.json in that case without any other fallout. In either event, 18.2 is missing a bunch of fixes over the last year and a half for both network, so I just pointed them at [17:49] copr/el-testing and asked for a reproducer [17:55] oops, sorry [18:02] blackboxsw: yeah, for a lot of reasons copr repo is a good iea there. [19:04] i approve: https://github.com/canonical/cloud-init/pull/132 [19:22] rharper: added your test: https://github.com/canonical/cloud-init/pull/53 [19:22] meena: rharper is done for the year, FYI. [19:29] powersj: blackboxsw: https://github.com/canonical/cloud-init/pull/130 <-- would be good to land this clarification to HACKING [19:35] Odd_Bloke: right, you mentioned that yesterday. [19:38] Odd_Bloke: you should also add how to do stuff at lp, cuz lotsa people find it confusing. [19:38] meena: "do stuff at lp"? [19:39] Odd_Bloke: how to fork stuff @ launchpad [19:39] and how to push there, cuz i've seen at least 2 found that challenging. [19:42] meena: Oh, for the CLA stuff? [19:43] Yeah, that would be good. [19:43] I was on vacation when the migration happened, so I don't really know how much the script handles etc. [19:54] i haven't looked at the script lately, tbf. so maybe it's magically fixed by now [19:54] meena: So regarding Cirrus CI, we'd be happy to introduce it as a non-voting status check provided it wouldn't cost us anything (which, looking at the docs, it shouldn't). So if you want to go take a look at making that happen, please feel free! [19:54] #130 is approved. I'll run through the migration tool again now in light of upstream now being in github to see if it works [19:55] meena: (For reference, when I was iterating on our Travis config, I just configured it against my fork, so hopefully you shouldn't need anything from us to get something working.) [19:56] Odd_Bloke: i've configured cirrus before: https://github.com/bsdci/libioc/blob/master/.cirrus.yml [19:57] Nice! [20:15] rharper, Odd_Bloke: I've addressed all your comments https://github.com/canonical/cloud-init/pull/61 and re-tested with FreeBSD 10, 11 and 12. Bonus point, I've pushed two extra fixes for minor issues. [20:15] I'm totally confident the branch can be merged. [20:18] I'll be testing it in a minute. [20:18] Goneri: Nice! [20:19] I'm uploading the refresh qcow2 images [20:27] Goneri: Looks like a pyflakes failure on #61 [20:37] naahh, it's impossible! [20:37] * Goneri takes a look [20:38] Goneri: Also it looks like you haven't migrated your CLA signature over to GitHub yet. [20:39] Goneri: https://cloudinit.readthedocs.io/en/latest/topics/hacking.html tells you how to do that (TL;DR: use tools/migrate-lp-user-to-github) [20:42] Odd_Bloke, https://github.com/canonical/cloud-init/pull/133 [20:46] Thanks! [20:59] Goneri: i got a stacktrace. [21:04] Goneri: ah, yeah, makes sense. https://gist.github.com/c4201008d52bc1bab7bd9cc81d217956 [21:05] meena, lets me guess IPV6 with CIDR notation? [21:05] absolutely. [21:05] lemme show you ;) [21:06] If we know IPv6 isn't supported yet, is that a blocker? [21:07] not really, I will just add a skip if netmask is null [21:07] OK, cool. [21:08] https://gist.github.com/92db11324aecb2ee1eb376745339ed65 [21:09] Goneri: you should skip everything that's None ;) [21:10] https://imgflip.com/i/3jzpiv [21:12] "review" https://github.com/canonical/cloud-init/pull/61#pullrequestreview-334933456 [21:17] meena, https://github.com/goneri/cloud-init/commit/3e6a1199031d9477ddd8d33234023f942a2ba79f [21:17] Goneri: per https://github.com/canonical/cloud-init/pull/133 I'm missing a correlating launchpad branch for you. and I expected the PR message was going to be something other than goneri as the username [21:18] blackboxsw: I closed out the MP. [21:18] blackboxsw: And what do you mean by "something other than goneri as the username"? [21:18] I'm confused too :-X [21:19] https://github.com/canonical/cloud-init/pull/133/files [21:19] that mp is open [21:19] That's a PR. [21:19] I closed the MP. [21:19] oops [21:19] ahhh [21:19] ok nevermind, you were on it Odd_Bloke [21:19] :) [21:20] I was expecting to see a branch in LP authored by [21:20] Gonéri Le Bouder [21:20] which I didn't realize mapped to goneri :) [21:20] blackboxsw: https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/377008 :) [21:20] and since I saw no branch over there I thought maybe it was an accidental wrong username supplied [21:20] Goneri: IPv4 could also be in CIDR notation. [21:20] +1 Odd_Bloke Goneri ... don't mind me [21:21] or? do we need to back-calculate it then? [21:23] meena, the existing code base does not support IPv4 CIDR notation, so it's not a regression. [21:27] and it's a corner case anyway, I doubt it happens often :-) [21:29] does any of the other renderers handle it? [21:30] If it's not supported on FreeBSD in the current codebase, I think we can land this PR without it. [21:30] meena: Do you disagree? [21:30] Odd_Bloke: aye, makes sense given that nothing much is supported in the current code base. [21:31] Cool. :) [21:34] meena: Goneri: So are we good to merge #61 (after an up-to-date CI run, of course)? Or do you want to do another round of testing? [21:35] i'll do another reboot and see what it does :O [21:35] also, can someone tell me why cloud-init would refuse to run my runcmd section? [21:35] I'm confident we won't see a horde of FreeBSD users coming on this channel in the coming days [21:35] I've to go, I will be back later today. [21:38] either, already ran on that instance (not per boot), bad yaml, or disabled runcmd in /etc/cloud/cloud.cfg(.d/*cfg) ? [21:39] blackboxsw: could be bad yaml… [21:40] blackboxsw: https://gist.github.com/90f3ea89f4339d2297a9f5a356e04b8d [21:40] meena: try this: sudo cloud-init query userdata > myud.yaml; cloud-init devel schema -c myud.yaml --annotate [21:41] it'll quickly vet your yaml at least [21:41] aye [21:41] runcmd. <- the dot [21:41] hrm nope ... sorry : it was offscreen for me on the laptop [21:42] blackboxsw: i'm thinking it's - # these comments probably don't work [21:43] yupp. that's what it is. [21:44] Cloud config schema errors: runcmd.2: None is not valid under any of the given schemas, runcmd.5: None is not valid under any of the given schemas, runcmd.8: None is not valid under any of the given schemas [21:44] lines 2, 5, and 8 are comments [21:45] ooh interesting. hrm. that schema is defined so validation was attempted. [21:45] Lines 2, 5 and 8 are empty list items followed by comments. [21:46] If the comment marker was before the -, everything would be fine. [21:46] I see, word wrap was making that hard to read for me [21:47] so the damage is self-inflicted. [21:47] ahh and meena I'd also expect to see something like 2019-12-19 21:43:05,262 - util.py[WARNING]: Failed to shellify .... into /var/lib/cloud/instances/loved-seal/scripts/runcmd [21:47] let's see. [21:47] in your /var/log/cloud-init.log [21:48] i'm pretty, and sure, i've posted the logs; but let's try again. [21:48] it would be nice if we bubbled up warnings to cloud-init status --long [21:48] blackboxsw: also, i'd expect that to be a slightly higher error level, so you know you fucked. [21:49] yeah fairly. though cloud-init walks a line and tries not to be fatal if some components are not run. runcmd may not be critical to the operation of the node. but it certainly is a case where the user should be alerted [21:50] blackboxsw: maybe it'd be cool if *i* could decide if runcmd is critical or not… [21:50] meena: heh truly [21:51] yeah, so cloud-init status only gives us errors: https://gist.github.com/126df102d581a75572fff2c74eb69b0f [21:51] yeah meena, it only bubbles up errors, it doesn't queue and raise warnings [21:51] and I think it may only bubble up one error (not all of them) [21:53] so there is improvement to be had there [21:54] it's worth a bug on runcmd not being rendered, at least we could raise the warning to error [21:55] and it's also a place that is a source of many many human-introduced errors [21:55] i don't have a WARNING failed to shellify blah, cuz it's failing earlier. (i reckon) [21:55] I'll post the logs maybe you can read them easier. [21:55] thanks [21:56] https://gist.github.com/6cfa360eb13d2c2396f6a4cea63c912d [21:56] https://gist.github.com/c6c5eb792918e252b5b21cda3b5c9c25 [21:58] -ENOGONERI [21:59] meena: I'm heading out now, but I'll check back in later because I'd love to get #61 landed. If Goneri returns, could the two of you decide if we're good to go and ping me to let me know? [22:03] Odd_Bloke: ok, cool — thanks for all the help [22:16] blackboxsw: https://bugs.launchpad.net/cloud-init/+bug/1801364 is fix-released ? [22:16] Ubuntu bug 1801364 in cloud-init "persisting OpenStack metadata fails" [Undecided,Fix committed] [22:18] smoser: should be as of 19.2-53-g067516d7b [22:19] which is Xenial ++ [22:19] so that bug should be Fix Relased [22:19] though [22:19] right? [22:19] not Committed ? [22:19] somehow it got missed [22:20] smoser: ahh right, I think this could be due to the shift to github. yes. I'll scrub the bug list that's been released and confir, [22:20] confirm even [22:34] i'm happy with Goneri's patch. but I'll add another patch to beautify the code a bit. [22:56] ok found 44 bugs released in 19.2 or later. only 17 or which were fix released. [22:56] I'm running a script now to close them out as fix released with the appropriate comment about the expected cloud-init version that released them [23:04] ok script complete, if anyone notices bugs in fix committed state that should be fix released please let us know. I'm adapting our release and publishing scripts to try to account for this gap. [23:34] thanks for the pretty red and green label colors OddBloke. I'm getting into the Christmas Spirit [23:38] otubo: if you get a chance in the next few days please run: ./tools/migrate-lp-user-to-github otubo otubo # to correlate your launchpad user to github user accounts [23:39] opened a fresh PR for Goneri: https://github.com/goneri/cloud-init/pull/2 [23:56] Goneri: https://github.com/goneri/cloud-init/pull/2 some æsthetics. [23:56] * meena → bed.