[16:08] <smoser> harmw, around ?
[16:09] <smoser> was looking to merge https://code.launchpad.net/~andatche/cloud-init/freebsd-improvements/+merge/278427
[16:09] <smoser> and interested in your thoughts on 'freebsd' ratehr than 'beastie'
[16:29] <Odd_Bloke> smoser: For GCE, they've asked us to set the MTU on network interfaces; is there a way in the new cloud-init networking world that we can say "apply this setting to all network interfaces"?
[16:30] <Odd_Bloke> (rharper: ^)
[16:30] <rharper> Odd_Bloke: no;  we don't have global tags
[16:32] <Odd_Bloke> rharper: Is that a "not currently" or a "that doesn't fit the model"?
[16:33] <smoser> it'd have to be done on the interfaces, there is no global settings.
[16:33] <rharper> Odd_Bloke: certainly not currently;  we've not discussed a global apply
[16:33] <smoser> it does seem to be an odd ask though
[16:33] <smoser> "always use mtu 1400"
[16:33] <rharper> heh, openstack does that with ovs
[16:33] <smoser> where as really it is device (connection) specific
[16:34] <Odd_Bloke> Well, if all the network interfaces are going to be virtualised the same, then it doesn't seem super-unreasonable.
[16:35] <Odd_Bloke> It does look like we could do it by editing dhclient.conf though.
[16:35] <Odd_Bloke> I _really_ wish there was a dhclient.conf.d.
[16:36] <smoser> Odd_Bloke, this is settable in dhcp
[16:36] <smoser>  option interface-mtu 9000
[16:37] <Odd_Bloke> Yeah, I'm building a test image now, I'll see what MTU it gets by default.
[16:38] <smoser> there were bugs where cirros wasnt respecting that
[16:38] <smoser> http://www.microhowto.info/howto/change_the_mtu_of_a_network_interface_using_dhcp.html
[16:39] <smoser> if our dhclient is not applying that setting, then that is something we can/should fix. i think we hit this with openstack.
[16:40] <Odd_Bloke> Looking at a leases file on an existing instance, GCE's DHCP server is sending it over.
[16:40] <Odd_Bloke> So hopefully this is all going to Just Work (TM). :p
[16:41] <smoser> well what does it show, Odd_Bloke
[16:41] <smoser> ifconfig should show the mtu
[16:43] <Odd_Bloke> smoser: Oh, right, because cloud-init is wiping away our hard-coded file?
[16:43] <Odd_Bloke> So, yes, it looks like eth0 got the right MTU. \o/
[16:43] <Odd_Bloke> (I thought we were still using our hard-coded file)
[16:43] <smoser> Odd_Bloke, right.k i opoened a bug for you on that
[16:44] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1563487
[16:44] <Odd_Bloke> smoser: Yep, that's what I'm looking at now.
[16:44] <smoser> ah. and you're assigned :)
[16:44] <Odd_Bloke> smoser: ^_^
[16:46] <Odd_Bloke> Yeah, so I had forgotten that the new cloud-init was wiping away our hard-coding, so I didn't think I was looking at an instance where the networking code was doing its thing. :)
[16:46] <Odd_Bloke> But I was.
[16:46] <Odd_Bloke> Next step: enable predictable interface names and see what happens
[16:47] <smoser> it "should work", and cloud-init should actually keep you getting the eth0 ones.
[16:47] <smoser> you shoudlt really need to re-build an imae to see immediate fallout
[16:47] <smoser> just remove /etc/udev/rules.d/* and /etc/systemd/network/* and /var/lib/cloud/* and reboot
[16:49] <Odd_Bloke> "keep you getting the eth0 ones"?
[16:49] <Odd_Bloke> s/you/you from/ ?
[16:49] <smoser> no. you should get the eth0
[16:49] <smoser> but reliably
[16:49] <Odd_Bloke> Oh, OK.
[16:50] <smoser> in that cllud-init writes rules that enforce the macs -> name
[16:50] <smoser> based on the first time that they were seen
[16:50] <smoser> so, basically its as if the old  udev persistent naming that autoomatically wrote rules
[16:50] <smoser> (without the blacklisting of "virtual" nics)
[17:04] <Odd_Bloke> smoser: So I've booted and I'm seeing ens4.
[17:04] <Odd_Bloke> (Which is fine, but doesn't match up with what you said before, so I'm checking that something isn't off)
[17:13] <cbolt-> i have an issue where i am injecting the network-interfactes into the metadata (using nocloud datasource) and the network interfaces arent up yet before the runcmd section in the user-data. any suggestions on how to deal with this? i am setting up routes via runcmd and the network not being up yet is problematic.
[17:36] <sputnik13> is there any requirement for an ISO configdrive other than the name for the volume?
[17:38] <sputnik13> created an ISO with my ssh key like described here https://github.com/kelseyhightower/coreos-vmware-tutorial
[17:38] <sputnik13> and ran a ubuntu cloud image under qemu with qemu-system-x86_64 -cdrom <iso> <cloud.img>
[17:38] <sputnik13> and the vm comes up and says it can't find any keys
[17:39] <sputnik13> but logs do show that the ISO is found and mounted
[17:39] <sputnik13> and openstack/latest/user_data is read
[17:39]  * sputnik13 is stumped
[17:39] <cbolt> what does your userdata contain?
[17:40] <sputnik13> http://pastebin.com/64EE0VSD
[17:40] <sputnik13> essentially
[17:43] <Odd_Bloke> smoser: We're seeing some problems in the way DataSourceConfigDrive handles network_config in precise (and trying to determine if the cloud we're working with are doing something wrong); are there any gotchas that I should be aware of?
[17:44] <smoser> Odd_Bloke, its probably racy
[17:44] <smoser> yeah, it is. i'm pretty sure
[17:45] <Odd_Bloke> smoser: But it's known to work?
[17:45] <smoser> maybe for some things.
[17:45] <smoser> basically have to know more of whats going on there./
[17:45] <smoser> and woudl have to think
[17:46] <Odd_Bloke> smoser: Because it looks to me like read_config_drive_dir_v2 will take the network_config content file and store it in metadata["network_config"] but then the code that should write it out look in metadata["network-interfaces"] and metadata["interfaces"].
[17:46] <smoser> you're looking at precise code or trunk code ?
[17:47] <cbolt> smoser: when you set network interfaces in metadata, does cloud-init wait until they come up before running the userdata?
[17:47] <Odd_Bloke> smoser: precise code.
[17:50] <Odd_Bloke> smoser: (Line 397 is the read; line 206 is the write, if you're following along at home)
[17:52] <Odd_Bloke> smoser: I'm EOD'ing, so I'll bug you more about this tomorrow. ^_^
[17:56] <smoser> cbolt, you're asking about config drive ?
[17:56] <cbolt> nocloud
[17:56] <smoser> on xenial,  yes.
[17:56] <smoser> it should do the rigth thing
[18:02] <larsks> sputnik13: fyi, using the ubuntu wily cloud image, using this user-data (http://chunk.io/f/f9ce25f474f04fd683847ad92234ea99) allowed me to log in to the 'ubuntu' user sans password with any errors.
[19:20] <bdx> smoser: any idea if cloud-init will support puppet4 (puppet-agent)?
[19:23] <bdx> oooh, nm, just found the bug for it
[19:26] <smoser> waldi, around ?
[19:58] <sputnik13> larsks did you do that on openstack or straight qemu with an ISO?
[19:59] <larsks> That was qemu + an iso (although I am using the nocloud format for the iso, rather than the openstack format)
[19:59] <larsks> sputnik13: ^^^
[19:59] <larsks> sputnik13: specifically, it was this iso image: http://chunk.io/f/ca6ca61dcf29402395c415a3e395e419
[20:00] <sputnik13> larsks: thanks, would you mind sharing the qemu options you used?
[20:01] <sputnik13> I know this all *should* work, I'm stumped as to what I might be missing
[20:01] <larsks> well, I'm booting with 'virsh', so that was: virt-install -n citest --disk vol=default/ubuntu-wily-x86_64.qcow2,bus=virtio --import --vnc --noautoconsole --disk path=/path/to/config.iso,device=cdrom -w network=default -r 1024
[20:02] <sputnik13> larsks: cool, thank you
[20:44] <sputnik13> larsks: that iso works with the image I had...  so it seems like your image is using the "NoCloud" option described here http://cloudinit.readthedocs.org/en/latest/topics/datasources.html
[20:44] <sputnik13> hmm, I wonder why the config-2 thing doesn't work
[20:59] <larsks> sputnik13: that's correct; that what I meant when I said I was using the nocloud format.  Sorry for not linking.  I have previously used the openstack config-drive format with success, but it's been a while.
[21:08] <rharper> smoser: http://paste.ubuntu.com/15621102/
[21:10] <rharper> ubuntu user not in /etc/passwd, so the ssh key add failed (xenial cloud image from 2016-04-03 )
[21:30] <sputnik13> larsks no worries, thanks for the hints, I was banging my head against the wall for a couple days
[22:47] <ybathia> harlowja: hi, is the admin_pass feature of cloudinit borken? I see the admin_pass value that I pass during nova boot in metadata.json
[22:47] <ybathia> but it does not seem to work
[22:47] <harlowja> ybathia i don't think cloud-init does admin_pass stuff
[22:47] <harlowja> that's more nova file injection
[22:48] <harlowja> from what i remember
[22:48] <spandhe> harlowja: hello :)
[22:49] <spandhe> harlowja: we see admin_pass in metadata.json. I also see https://github.com/openstack/cloud-init/blob/d0f880277b152ecf82aa2e15a281ffc02ff5eaac/cloudinit/sources/openstack/base.py#L113 . but its not being called from anywhere
[22:51] <harlowja> spandhe  ya, probably look at the 0.7.x branch
[22:51] <spandhe> harlowja: the method is not there on that branch
[22:51] <harlowja> then, ya, i guessed its not used by cloud-init
[22:52] <harlowja> nova afaik injected that password into the disk(s)