[17:08] <rharper> smoser: where does the cloud-init package handle the debconf_setselection inputs from maas?  what parses that and renders those .cfg files ?
[17:23] <smoser> rharper, .postinst
[17:23] <rharper> thanks
[17:23] <logan-> I'm trying to hunt down docs on how to configure the renderer for /etc/network/interfaces.d/50-cloud-init.cfg that is generated on Xenial images. I'd like it to render with v6 configuration in addition to v4.
[17:24] <smoser> logan-, what do you have now ?
[17:24] <smoser> where are you running ?
[17:25] <smoser> basiclaly cloud-init reads from the datasource to get the networking information
[17:25] <smoser> if it finds nothing it renders "dhcp on eth0"
[17:25] <smoser> there is not currently a way to configure that to use dhcpv6 on eth0
[17:25] <logan-> http://cdn.pasteraw.com/k10obywd29qws85z8q976qwnkk0nxdt (+ prepended to the line I need)
[17:26] <logan-> on an Openstack based cloud
[17:26] <logan-> gotcha. thanks
[17:28] <jgrimm> smoser, rharper:  we still need this, yes? https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/317917
[17:28] <rharper> y
[17:29] <smoser> logan-, are you able to use config drive ?
[17:29] <smoser> if so, it might "just work"
[17:29] <smoser> if not, its more complicated...
[17:29] <jgrimm> we should try to get that landed next, i'd think
[17:29] <smoser> there is no way for cloud-init to know if it shoudl dhcp v6 or not if it doesnt have a datasource telling it what to do
[17:30] <smoser> jgrimm, ack
[17:30] <logan-> I was just looking thru the metadata being exposed at http://169.254.169.254/openstack/latest/network_data.json, it seems to be missing ipv6. maybe it is an openstack metadata service issue :)
[17:31] <jgrimm> smoser, rharper: cool, just trying to line things up for landing (once ds-identify is up)
[17:39] <smoser> rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/318975
[17:39] <smoser> you're just complainig about the 'd', right?
[17:40] <rharper> smoser: yes, enable|disable vs enable[d]|disabled[d]
[17:40] <rharper> pick one, for both places their used, IMO
[17:40] <rharper> it's documented properly; but easy to misremember
[17:41] <smoser> fixed.
[17:43] <rharper> thanks
[17:44] <logan-> in /etc/cloud.cfg.d/, are yaml overrides to dicts treated as complete overrides of the dict or is the earlier dict merged with later overrides using .update()? ie I want to override system_info: { package_mirrors: {} }, can I just enumerate package_mirrors in the override dict, or do I need to redefine the whole system_info
[18:24] <smoser> rharper, you ACK that review ?
[18:47] <rharper> smoser: I'll do that now
[19:22] <powersj> FYI getting CI automation going on cloud-init today, so some reviews might start showing up
[19:42] <rharper> powersj: \o/ cool
[20:06] <powersj> *sigh*
[20:07] <powersj> this is what is going to happen for nearly every cloud-init CI run:
[20:07] <powersj> http://paste.ubuntu.com/24126637/
[20:09] <magicalChicken> powersj: it may be worht looking into the bddeb cloud tests branch again
[20:09] <magicalChicken> it currently still requires tags to be in place
[20:09] <magicalChicken> but we were talking before about updating packages/bddeb and the bddeb in a container feature to be able to generate a debian/ on its own
[20:10] <magicalChicken> and it may be possible to have some sort of workaround to have a temporary tag with that
[20:10] <powersj> so remind me, that branch was to automatically build a deb, however in this case I'm just trying to run tox, which will package up the code. I don't exactly what a deb in that case.
[20:11] <magicalChicken> yeah that was to build a deb from current tree and run cloud-tests with the deb
[20:11] <magicalChicken> so not quite the same thing, nvm
[20:12] <powersj> I still think this should be "fixed" somehow, as this means the person proposing the merge definitely did not run tox, but also could not run tox until they know that they need to pull the tags
[20:12] <magicalChicken> i think they could still have the tags locally, they just forgot to push the tags out to their repo
[20:12] <magicalChicken> that's what happened with mine before
[20:13] <powersj> ah right
[20:13] <powersj> put what other projects require you to push tags and keep them up-to-date...
[20:13] <magicalChicken> it may also work to just have git pull tags from the main repo
[20:14] <powersj> magicalChicken: is git clone for you slow at times?
[20:14] <powersj> I've noticed it can be, but this is a first: http://paste.ubuntu.com/24126670/
[20:14] <magicalChicken> launchpad sometimes times out on me for random stuff, it may just be a glitch
[20:15] <nacc> powersj: working fine for me at home
[20:15] <magicalChicken> its working for me too right now
[20:15] <powersj> nacc: thx
[20:15] <powersj> k
[22:10] <Odd_Bloke> smoser: Can one override the frequency of a config module using /etc/cloud.cfg{,.d/*}?
[22:10] <smoser> yes.
[22:11] <smoser> https://git.launchpad.net/cloud-init/tree/doc/examples/cloud-config.txt#n147
[22:11] <smoser> but not without re-declaring the list.
[22:11] <smoser> and generally you shouldnot have to do that.
[22:12] <Odd_Bloke> smoser: We have a cloud who want to do password configuration (i.e. cc_set_password) every boot; thoughts on how else we could enable them to do that?
[22:14] <smoser> well cloud-init wont re-read the metadata ever boot, so it wouldnt know that that got changed.
[22:14] <smoser> so without more thinking i dont have an easy way to do what you're after.
[22:14] <Odd_Bloke> Ah, right, of course.
[22:16] <Odd_Bloke> Ah, OK, perhaps we've misunderstood what they were trying to achieve.
[22:16] <Odd_Bloke> (They ship a modified cc_set_password.py.)
[22:16] <rharper> =(
[22:18]  * powersj pushes the 'go go ci button'
[23:07] <powersj> well... first round of CI looks good :D
[23:08] <jgrimm> \o/