=== sterfield_ is now known as sterfield === sterfield_ is now known as sterfield === sterfield_ is now known as sterfield === sterfield_ is now known as sterfield [16:08] harmw, around ? [16:09] was looking to merge https://code.launchpad.net/~andatche/cloud-init/freebsd-improvements/+merge/278427 [16:09] and interested in your thoughts on 'freebsd' ratehr than 'beastie' [16:29] 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] (rharper: ^) [16:30] Odd_Bloke: no; we don't have global tags [16:32] rharper: Is that a "not currently" or a "that doesn't fit the model"? [16:33] it'd have to be done on the interfaces, there is no global settings. [16:33] Odd_Bloke: certainly not currently; we've not discussed a global apply [16:33] it does seem to be an odd ask though [16:33] "always use mtu 1400" [16:33] heh, openstack does that with ovs [16:33] where as really it is device (connection) specific [16:34] Well, if all the network interfaces are going to be virtualised the same, then it doesn't seem super-unreasonable. [16:35] It does look like we could do it by editing dhclient.conf though. [16:35] I _really_ wish there was a dhclient.conf.d. [16:36] Odd_Bloke, this is settable in dhcp [16:36] option interface-mtu 9000 [16:37] Yeah, I'm building a test image now, I'll see what MTU it gets by default. [16:38] there were bugs where cirros wasnt respecting that [16:38] http://www.microhowto.info/howto/change_the_mtu_of_a_network_interface_using_dhcp.html [16:39] 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] Looking at a leases file on an existing instance, GCE's DHCP server is sending it over. [16:40] So hopefully this is all going to Just Work (TM). :p [16:41] well what does it show, Odd_Bloke [16:41] ifconfig should show the mtu [16:43] smoser: Oh, right, because cloud-init is wiping away our hard-coded file? [16:43] So, yes, it looks like eth0 got the right MTU. \o/ [16:43] (I thought we were still using our hard-coded file) [16:43] Odd_Bloke, right.k i opoened a bug for you on that [16:44] https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1563487 [16:44] smoser: Yep, that's what I'm looking at now. [16:44] ah. and you're assigned :) [16:44] smoser: ^_^ [16:46] 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] But I was. [16:46] Next step: enable predictable interface names and see what happens [16:47] it "should work", and cloud-init should actually keep you getting the eth0 ones. [16:47] you shoudlt really need to re-build an imae to see immediate fallout [16:47] just remove /etc/udev/rules.d/* and /etc/systemd/network/* and /var/lib/cloud/* and reboot [16:49] "keep you getting the eth0 ones"? [16:49] s/you/you from/ ? [16:49] no. you should get the eth0 [16:49] but reliably [16:49] Oh, OK. [16:50] in that cllud-init writes rules that enforce the macs -> name [16:50] based on the first time that they were seen [16:50] so, basically its as if the old udev persistent naming that autoomatically wrote rules [16:50] (without the blacklisting of "virtual" nics) [17:04] smoser: So I've booted and I'm seeing ens4. [17:04] (Which is fine, but doesn't match up with what you said before, so I'm checking that something isn't off) [17:13] 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. === cbolt- is now known as cbolt [17:36] is there any requirement for an ISO configdrive other than the name for the volume? [17:38] created an ISO with my ssh key like described here https://github.com/kelseyhightower/coreos-vmware-tutorial [17:38] and ran a ubuntu cloud image under qemu with qemu-system-x86_64 -cdrom [17:38] and the vm comes up and says it can't find any keys [17:39] but logs do show that the ISO is found and mounted [17:39] and openstack/latest/user_data is read [17:39] * sputnik13 is stumped [17:39] what does your userdata contain? [17:40] http://pastebin.com/64EE0VSD [17:40] essentially [17:43] 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] Odd_Bloke, its probably racy [17:44] yeah, it is. i'm pretty sure [17:45] smoser: But it's known to work? [17:45] maybe for some things. [17:45] basically have to know more of whats going on there./ [17:45] and woudl have to think [17:46] 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] you're looking at precise code or trunk code ? [17:47] smoser: when you set network interfaces in metadata, does cloud-init wait until they come up before running the userdata? [17:47] smoser: precise code. [17:50] smoser: (Line 397 is the read; line 206 is the write, if you're following along at home) [17:52] smoser: I'm EOD'ing, so I'll bug you more about this tomorrow. ^_^ [17:56] cbolt, you're asking about config drive ? [17:56] nocloud [17:56] on xenial, yes. [17:56] it should do the rigth thing [18:02] 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] smoser: any idea if cloud-init will support puppet4 (puppet-agent)? [19:23] oooh, nm, just found the bug for it [19:26] waldi, around ? [19:58] larsks did you do that on openstack or straight qemu with an ISO? [19:59] That was qemu + an iso (although I am using the nocloud format for the iso, rather than the openstack format) [19:59] sputnik13: ^^^ [19:59] sputnik13: specifically, it was this iso image: http://chunk.io/f/ca6ca61dcf29402395c415a3e395e419 [20:00] larsks: thanks, would you mind sharing the qemu options you used? [20:01] I know this all *should* work, I'm stumped as to what I might be missing [20:01] 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] larsks: cool, thank you [20:44] 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] hmm, I wonder why the config-2 thing doesn't work [20:59] 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] smoser: http://paste.ubuntu.com/15621102/ [21:10] ubuntu user not in /etc/passwd, so the ssh key add failed (xenial cloud image from 2016-04-03 ) [21:30] larsks no worries, thanks for the hints, I was banging my head against the wall for a couple days [22:47] 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] but it does not seem to work [22:47] ybathia i don't think cloud-init does admin_pass stuff [22:47] that's more nova file injection [22:48] from what i remember [22:48] harlowja: hello :) [22:49] 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] spandhe ya, probably look at the 0.7.x branch [22:51] harlowja: the method is not there on that branch [22:51] then, ya, i guessed its not used by cloud-init [22:52] nova afaik injected that password into the disk(s)