[11:49] rharper: smoser: Happy release day! I've just realised/discovered that lxd images still write out eth0.cfg when they are launched; they use this template: http://paste.ubuntu.com/15963686/. Does http://paste.ubuntu.com/15963681/ look like a reasonable replacement for that to drop in to /var/lib/cloud/seed/nocloud-net/network-config ? [11:50] (That seed directory is the same one they use for everything else) [11:51] My testing suggests that it is, but I wanted to get your eyes on it first. :) [11:51] (The interface we care about will always be called eth0) [12:34] Odd_Bloke: the control field can always be auto; ie, do you want ifupdown to make sure the iface is 'up'; [12:58] Odd_Bloke, that does seem right. [12:58] Odd_Bloke, fwiw, it does work right now for 'dhcp' [12:59] cloud-init deletes the 'eth0.cfg' file that has the rendered template [12:59] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/1210 [13:00] rharper, this mioght have been the issue you were seeing that i coudl not reproduce. [13:00] if you got 'manual' written there. [13:00] smoser: Even if cloud-init didn't delete it, it'd be fine for the dhcp case; it's the manual case that's the problem. :p [13:01] manual case is for when you're doing link-local only networking [13:01] hence the check in the lxd config get [13:01] Yeah, and then we don't want to dhcp, so fallback config would also be wrong. [13:01] now, I think we want control: auto (which we didn't have before) [13:02] Odd_Bloke: right, in the case one wants to use link-local, then we need subnet: manual and control: auto [13:02] I think that will have ifup "up" the iface; I'm not sure if that's enough for link-local to work; but it's likely better than ignoring it altogether unless some other part of lxd up's the iface [13:03] and certainly better than attempting to dhcp on a the iface with no dnsmasq setup to respond [13:03] IIUC the problem [13:03] I should add a link-local set to curtin networking [13:03] https://bugs.launchpad.net/cloud-images/+bug/1573000 is the bug. [13:04] ah [13:04] indeed, so providing a config to cloud-init would prevent the writeout of the fallback dhcp [13:04] Yeah. [13:05] where is your diff, Odd_Bloke ? the changes your proposing ? [13:05] in the bug [13:05] http://paste.ubuntu.com/15963681/ as well [13:05] smoser: There is no cloud-init diff, this is just about the network config lxd would write out to its seed. [13:06] what should i write to get this ? [13:07] er... how do i answer questions in dpkg-reconfigure lxd to get this [13:07] disable the bridge [13:07] I think you want to say no to lxdbr0 ? [13:07] http://paste.ubuntu.com/15965001/ [13:07] trying that [13:08] lxd ships in link-local mode. [13:08] So we are in the not-quite-working case in the images by default. [13:09] If you configure the bridge, then the lxd image and cloud-init write out configuration that agrees. [13:09] WHich is still a bug, but less noticeable. [13:09] You can easily fake one or the other with "-c user.network_mode=link-local" and "-c user.network_mode=" when launching a container. === rangerpbzzzz is now known as rangerpb [13:16] http://paste.ubuntu.com/15965123/ [13:16] so that seems like it should work. [13:17] smoser: Yeah, I've tested it; it works as I expect. Just checking if there are gotchas that I'm not seeing. :) [13:17] Odd_Bloke, if you dont have a reason, i'd prefer 2 spaces for indentation levels rather than 4. but i dont have a good reason as to why. [13:17] (in the template you're writing) [13:18] smoser: The rest of the lxd templating stuff is YAML using 4 spaces, so I'll stick with that. I'll add you as a reviewer once I have something. :) [13:20] its just obnoxiously wide. but consitency is better. [13:20] rharper: So were you earlier saying that I probably wanted 'control: auto' for both cases? [13:20] what we really need though is for [13:21] %{network_config.yaml} [13:21] or soemthign to that affect. [13:21] i geuss, need to declare the version that we want also [13:21] but. [14:10] Hello all, will someone give me a helping hand? tl;dr: cloud-init + multiple nics brings up only first interface. Metadata service is available and reachable (openstack). [14:29] rharper: (Did you see my earlier Q? "So were you earlier saying that I probably wanted 'control: auto' for both cases?") [14:30] Odd_Bloke: sorry, if I missed it; yes; control: auto means that network target will attempt to make sure any 'auto' iface is up before continuing; [14:30] OK, cool. [14:30] what's not clear to me, without testing, is in the link-local case; what ifupdown does with auto [14:31] basically ifquery will return the iface name if it's marked auto; and then I think ifup would need to touch the file in /run/network/$Iface.XXX to know that its up; if ifup on a linklocal doesn;t do that [14:31] then it'll fail and cause cloud-init not to continue (no network!) [14:32] rharper: OK, I'll investigate what happens. :) [14:32] so we need to confirm that either manaul is fine (and the network comes up OK) or auto (and that ifup on a link-local) does the right thing [14:32] cool [14:33] rharper: (I've seen that configuration there work as expected FWIW, but I'll see what auto does if you think it's more correct (if it works :p)) [14:33] Odd_Bloke: right, my thoughts as well [15:09] hold on. [15:09] you want auto [15:09] control: auto [15:09] on both. [15:11] its very odd actually. [15:11] i think there is a bug in ifupdown there. [15:12] iface eth0 inet manua [15:12] wiuthout 'auto eth0' or 'allow-auto eth0' [15:12] should not show the device as up [15:14] what a mess. [15:19] http://paste.ubuntu.com/15966891/ [15:30] rharper, ^ . so if you put 'manual' then it comes up auto [15:30] which i think i a bug [15:30] the 2 calls i realize now are because i had an 'eth0.cfg' file , which we're fixing :) [15:31] that sounds like a bug [15:32] pretty sure manual means (don't up this yourself) [15:32] yeah, so part of htat above is user fail [15:33] i had multiple stanzas [15:33] ah [15:33] hehe [15:33] actually it odd that auto eth0 [15:33] yes [15:33] auto eth0 [15:33] auto eth0 [15:33] brings it up 3 times [15:33] i think [15:33] but ignore that. [15:33] just putting this in: [15:33] iface eth0 inet manual [15:34] means that the interface *is* up (listed in ifconfig without -a) [15:34] but no ifup hooks are called [15:34] smoser: hangout [15:34] yeah, so that said, we should declare it auto [15:35] agreed, Odd_Bloke is testing that it DTRT for link-local [15:35] It looks like it DTRT with auto. [15:37] i think you end up with link local with 'manual' with or without auto [15:37] which i kind ofthink is a bug [15:38] interesting [15:55] rharper, opened https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1573112 [16:01] ok [18:00] Odd_Bloke, https://code.launchpad.net/~daniel-thewatkins/cloudware/+git/cpc_build_tools/+merge/292557 just commented there. sorry didnt' look earlier [18:10] http://paste.ubuntu.com/15970544/ [18:15] smoser: Oh, shoot, I copy-pasted from an old version on my test box. [18:15] smoser: Thanks. :) [18:17] Odd_Bloke, what do you think about 'copy' ? [18:17] i really think you dont want it [18:17] as interfaces.tpl didnt have it. [18:17] smoser: Right, but all the other cloud-init bits _do_ have it. [18:17] smoser: So I was on the fence. [18:17] and for 16.04 we should kill those upstart.X files [18:18] smoser: Right; let's get networking fixed first though. ;) [18:18] what does 'copy' mean ? [18:18] smoser: I believe it means that the file will be regenerated when a container is copied to become a new container. [18:18] that the rendered file should be coied when the image is copied (from inside the instance) or that the template shoudl be copied. [18:18] But I mostly cargo-culted it. [18:19] hm.... [18:19] smoser: It was more important when we were using the MAC address in there, but it turned out we didn't need it, which simplified matters. [18:19] yeah, but only "mostly" [18:19] :) [18:20] well, with or without the mac, it would need to be re-rendered when you start a new image [18:20] right ? [18:20] Right, because network_mode might have changed. [18:20] right. [18:20] so whatever means *that* is what we want [18:21] smoser: So in lxd/container_lxc.go, at line 2677 [18:22] FAIL [18:22] At line 2702, the trigger is compared against the "when" list and if it's found the template is run. [18:22] So I believe having 'copy' there is what we want. [18:23] It looks like the triggers used are "start", "create", and "copy". [18:24] Bah, I accidentally cleaned up my test host. [18:24] i still dont knwo what 'copy' means. [18:24] start and create somewhat make sense to me [18:24] smoser: 'copy - Copy containers within or in between lxd instances.' [18:24] and i had strgraber ask you all to change to just 'create' rather than 'start' [18:25] live? [18:25] or images [18:25] I think that would be 'move - Move containers within or in between lxd instances.' [18:26] i still dont understand what it means. why would i care about rendering a file on 'copy' [18:26] if i'm going to have to 'start' or 'create' it on the other side after i 'copy' it. [18:27] smoser: But you might not want to regenerate a template for _every_ start. [18:27] that does make some sense, yes. [18:28] (although i doubt you really want it as if your container goes down unintended it will get re-rendered , in addition to explicit 'stop' and 'start') [18:28] but thats beside the point. [18:28] we do not want 'start'. we want create. [18:29] Yep. [18:30] hm.. [18:30] why is that mp private ? [18:30] maybe i should not ask that in public :) [18:30] but we probably need to ask stgraber what we want to do here. [18:30] and we could/should do that in lxc-dev. [18:32] * larsks wonders why there is a set_hostname method in the Azure data source. [18:33] smoser: Yeah, I was going to get stgraber to review as well. [18:33] But I'll pick this up tomorrow morning; I want to finish off the last release bits I have and then EOD. :) [19:08] Odd_Bloke: it looks like you are responsible for large chunks of the azure data source? If that's true, got a moment for a couple of questions? === rangerpb is now known as rangerpbzzzz [20:15] larsks: Drop me an email at daniel.watkins@canonical.com? [20:17] Odd_Bloke: Sure, if that's your preference. [20:17] larsks: Yeah, I'll grab you on here once I've read through. [20:18] larsks: (I'm UK based, so I'm not really here ATM) [20:18] *disappears in a cloud of smoke* [20:18] Odd_Bloke: I figured from your EOD comment earlier :)