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