[04:06] Hello [04:07] Do we have any guide to use cloud-init on freebsd? === cpaelzer_ is now known as cpaelzer [16:04] blackboxsw, http://paste.ubuntu.com/25363324/ [16:04] that'd be the yaml like syntax that i thought might throw you fits [16:05] and then second, like this: http://paste.ubuntu.com/25363330/ [16:05] those are yaml "anchors" [16:06] smoser: that might actually throw jsonschema fits (self-referential stuff & json) hmm [16:06] good examples. I'll play with them smoser [16:11] well, they're valid to json schema [16:11] because yaml.load() returns you a dictionary with all things "copied out" [16:13] ie, the result of cloudinit.safeyaml.load() is always somethign that jsonschema can look at. json schema doesn't actually look at the "S" in JSON ("serialized"), but rather it looks at the "O" ("object"). [16:13] and yaml.load() returns a object [16:33] ok smoser rharper all changes pushed to the analyze branch https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/328819 CI works [16:33] k [16:45] smoser: if the sbuild of the new release package is good, do you want us to push the upstream tag ? [17:03] Folks, cloud-init with config drive on openstack instance incorrectly sets the dns-nameservers on the loopback interface. Rest of the configuration is correctly set on eth0. Any ideas to troubleshoot this ? [17:03] I am running Ubuntu 16.04 [17:08] sabari: it's not an incorrect setting, are you not seeing the values show up in /etc/resolv.conf ? [17:09] the resolvconf package will read any of the dns-* settings across any interface, including lo; [17:09] rharper, i guess you could propose a merge [17:09] and i could then pull, build, push [17:10] smoser: ok, let me see if I can get that working [17:10] I suspect I'll need to push my tags to my remote branch [17:11] right. i guess the only tag that matters is ubuntu/<...> [17:11] and i can just as well tag that and push [17:11] rharper: /etc/resolv.conf is empty. When I use cloud-init with metadata service, the dns-nameservers are set on eth0 and hence I expected the same with configdrive as datasrouce. [17:11] sabari, that is odd. [17:12] well, or maybe not. [17:12] so the difference between info from the openstack api and the config drive is that cloud-init will read all the networking config from the config drive and apply it form config drive. [17:13] but it does not currently do that for the metadata service. [17:13] smoser: configdrive *may* include an eni vs. network_data.json [17:14] and IIRC< it prefers the eni vs network_data.json ; where as meta-data service, only has network_data.json ? do I have that right? [17:14] ISTR an issue w.r.t an 'eni' in the config and a 'network_data.json' [17:14] and cloud-init had to make a choice w.r.t which one has precendence [17:14] possibly the eni included does not match what's in network_data.json [17:15] rharper: I only see network_data.json in the mounted iso. I don't see an ENI. Let me check again. [17:16] if you can, could you share the network_data.json ? I can render that locally and see what eni cloud-init should generate [17:16] rhaper: sure [17:17] rharper: http://paste.openstack.org/raw/618941/ [17:18] well... [17:18] so cloud-init is putting those on 'lo' as they're "global" dns servers. [17:19] theres no specific data that says these are attached to eth0. [17:19] obviously you could come up with rules to figure that out but cloud-init does not do that at the moment. [17:20] smoser: I see. So the global dns-servers are set only on the lo interface. rharper mentioned that resolconf is supposed to read it and set to /etc/resolv.conf, let me try to check that. [17:21] well, yeah. resolvconf will apply dns nameservers [17:21] on each interface as it comes up [17:21] and as 'lo' came up, and had dns-nameservers, it should have made its way into /etc/resolv.conf [17:22] smoser: hrm, the openstack helper makes local renedering unhappy because of that known_macs feature [17:23] net-convert used to work on those files; will need to fix that [17:23] ? [17:23] it will work, you just have to pass in the macs [17:23] right [17:23] that's work for net-convert [17:23] to pull them out of the json and pass it to the method for rendering [17:23] bbiab [17:23] right. you could do that. [17:25] smoser, rharper: thanks for all the info. Let me debug what's happening with resolconf and get back. [17:32] rharper: looks like there is support in cloud-init for setting a sortlist in resolv.conf however LP: #1711967 says there is an issue with that [17:32] Launchpad bug 1711967 in cloud-init "dns-sortlist" [Undecided,New] https://launchpad.net/bugs/1711967 [17:35] rharper, sabari note, this is upstream related [17:35] https://review.openstack.org/#/c/467699/ [17:35] ie, them fixing the dns info to be per-interface [17:36] i had started cloud-init chagnes at http://paste.ubuntu.com/25220242/ [17:43] smoser: Thanks a lot for the upstream patch! It will try it out and hopefully that will fix the problem :) [17:43] sabari, well, cloud-init does not support it yet.. eventually it would. [17:45] smoser: Ah, I see. So this also needs the corresponding cloud-init fix that you referenced. [17:50] smoser: Little confused here..If I patch nova with the upstream change, the existing cloud-init should be able to set the nameserver on eth0 as well right ? Or does I need the changes you are working on. [17:50] *do I [17:55] you'd also need cloud-init changes to take advantage of the upstream change. [17:56] the upstream change was basically upstream realizing "hey, dns servers generally available per-interface." [18:07] blackboxsw, https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/328241 [18:07] checking [18:07] did you see ajogen's comments ? [18:08] hrm saw all of his initial comments, didn't see that last one [18:21] smoser: https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/329324 see if I did that right; I pushed with --tags which pushed *all* my tags; not sure if that's correct [18:23] rharper: fwiw, your tags are relatively irrelevant to a git merge [18:23] rharper: not sure entirely on the context, just an fyi [18:31] nacc: yeah; I figured; we're documenting upstream release into ubuntu/devel process, so it includes a few tag steps that are meant for :master but if I'm preparing the changes in a branch , hoping to bring the needed single tag along but we'll have to see what works here [18:33] rharper: so you can push a single tag with `git push ` and git should figure it out (tags are a special ref case). You can also push with a refspec `git push refs/tags/:refs/tags/' [18:33] rharper: yeah, what you wrote makes sense, though -- if you need any help, let me know [18:34] nacc: ah, that make sense (for single tag push0 [18:34] ) [18:49] rharper, you picked the wrong target [18:49] for the merge [18:49] https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/329324 [18:49] you dont want to 'Merge into:' target [18:49] you want into ubuntu/artful [18:49] or ubuntu/devel, probably? [18:49] right [18:50] they presumably point to the same thing [18:50] our general hope is for 'ubuntu -> ubuntu merges', ubuntu/devel can always be the target [18:50] and for ubuntu -> debian merges, debian/sid can always the target [18:56] smoser: ah, right [18:56] do I just kill the MP and resubmit ? [18:57] rharper: i think you can just resubmit it from the web UI and pick a new target [19:05] rharper, i rejected it :). you can't (or i couldnt) change the target. maybe you can, but resubmit with different target is as easy [19:05] smoser: yeah, user can resubmit and change it, iirc, but not with the existing MP [19:12] smoser: k [19:14] hrm, LP doesn't like ubuntu/artful [19:49] rharper: did you get an error? i see it existing: https://code.launchpad.net/~usd-import-team/ubuntu/+source/cloud-init/+git/cloud-init/+ref/ubuntu/artful [19:53] nacc: I did, complained that it didn't recognize ubuntu/arful ; I used ubuntu/devel instead [19:53] artful [19:53] even [19:53] rharper: hrm, strange [20:33] smoser: nacc: hrm, so it doesn't like ubuntu/* whatever the first time; it reports an error, but if you just resubmit, then it works. .. [20:33] maybe a git/launchpad integration error ? [20:34] smoser: https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/329332 [20:38] rharper, you dont have a ubuntu/0.7.9-243-ge74d775-0ubuntu1 tag pushed. [20:38] https://git.launchpad.net/~raharper/cloud-init/refs/tags?h=ubuntu-devel-new-artful-release-v2 [20:39] not a big deal, i can just tag and push there. [20:39] i think what you wanted would have been: [20:39] git tag ubuntu/0.7.9-243-ge74d775-0ubuntu1 [20:39] git push HEAD ubuntu/0.7.9-243-ge74d775-0ubuntu1 [20:39] smoser: well, I wanted to push it, but I couldn't quite figure out how to specify my branch remote; [20:39] smoser: I've done the tag [20:40] but not sure how to push with -u raharper (which expands to the lp remote) [20:41] smoser: that last one worked ( had to look up my remote name ) [20:41] maybe I was just missing the HEAD , git push -u raharper HEAD [20:47] head would have been same as 'ubuntu/devel' [20:48] git push raharper ubuntu/devel ubuntu/0.7.9-243-ge74d775-0ubuntu1 [20:48] or [20:48] git checkout ubuntu/devel && git push raharper HEAD ubuntu/0.7.9-243-ge74d775-0ubuntu1 [20:49] and i just uploaded that and pushed. [20:50] cool [20:54] rharper: the syntax you listed `git push remote HEAD ` doesn't do what you think most likely :) [20:54] well, it depends on what you're trying to do, i suppose [20:54] you very rarely push HEAD explicitly like that [20:56] nacc: I think you want to ping smoser; I was blindly trying what smoser suggested; I think smoser has resolved to something more repeatable with the git push ubuntu/devel (or whatever my local branch with the change sare on) [20:56] which should work regardless of what HEAD is pointing at (which I think is your point) [20:57] rharper: right, you want to push a local branch and tag? [20:57] yeah [20:57] rharper: and use the same naming on the remote, it seems like? [20:57] yes [20:57] rharper: yep `git push ` is perfect then. And by default, with `git ubuntu`, the remote name is your lp username [20:58] rharper, https://lists.ubuntu.com/archives/artful-changes/2017-August/008659.html [20:58] smoser: thanks! [20:58] rharper, it is easy to think that [20:58] git push

[20:58] but that is not the syntax [20:58] its [20:59] git push

[:] [...] [20:59] I know of the colon; I used that often for branches [20:59] it's the tag that was confusing [20:59] yeah [20:59] I guess tag goes in [...] ? [20:59] just keep in mind that everything after remote is a refspec [20:59] git push raharper my-local-branch:my-remote-branch-name ? [20:59] so any refspec is allowed and those without colons are degenerate cases