| === sterfield_ is now known as sterfield | ||
| === sterfield_ is now known as sterfield | ||
| === sterfield_ is now known as sterfield | ||
| === sterfield_ is now known as sterfield | ||
| smoser | harmw, around ? | 16:08 |
|---|---|---|
| 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:09 |
| 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:29 |
| Odd_Bloke | (rharper: ^) | 16:30 |
| rharper | Odd_Bloke: no; we don't have global tags | 16:30 |
| Odd_Bloke | rharper: Is that a "not currently" or a "that doesn't fit the model"? | 16:32 |
| 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:33 |
| Odd_Bloke | Well, if all the network interfaces are going to be virtualised the same, then it doesn't seem super-unreasonable. | 16:34 |
| 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:35 |
| smoser | Odd_Bloke, this is settable in dhcp | 16:36 |
| smoser | option interface-mtu 9000 | 16:36 |
| Odd_Bloke | Yeah, I'm building a test image now, I'll see what MTU it gets by default. | 16:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| smoser | well what does it show, Odd_Bloke | 16:41 |
| smoser | ifconfig should show the mtu | 16:41 |
| 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:43 |
| 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:44 |
| 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:46 |
| 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:47 |
| 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:49 |
| 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) | 16:50 |
| 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:04 |
| 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:13 |
| === cbolt- is now known as cbolt | ||
| sputnik13 | is there any requirement for an ISO configdrive other than the name for the volume? | 17:36 |
| 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:38 |
| 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:39 |
| sputnik13 | http://pastebin.com/64EE0VSD | 17:40 |
| sputnik13 | essentially | 17:40 |
| 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:43 |
| smoser | Odd_Bloke, its probably racy | 17:44 |
| smoser | yeah, it is. i'm pretty sure | 17:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| Odd_Bloke | smoser: (Line 397 is the read; line 206 is the write, if you're following along at home) | 17:50 |
| Odd_Bloke | smoser: I'm EOD'ing, so I'll bug you more about this tomorrow. ^_^ | 17:52 |
| 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 | 17:56 |
| 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. | 18:02 |
| bdx | smoser: any idea if cloud-init will support puppet4 (puppet-agent)? | 19:20 |
| bdx | oooh, nm, just found the bug for it | 19:23 |
| smoser | waldi, around ? | 19:26 |
| sputnik13 | larsks did you do that on openstack or straight qemu with an ISO? | 19:58 |
| 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 | 19:59 |
| sputnik13 | larsks: thanks, would you mind sharing the qemu options you used? | 20:00 |
| 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:01 |
| sputnik13 | larsks: cool, thank you | 20:02 |
| 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:44 |
| 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. | 20:59 |
| rharper | smoser: http://paste.ubuntu.com/15621102/ | 21:08 |
| rharper | ubuntu user not in /etc/passwd, so the ssh key add failed (xenial cloud image from 2016-04-03 ) | 21:10 |
| sputnik13 | larsks no worries, thanks for the hints, I was banging my head against the wall for a couple days | 21:30 |
| 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:47 |
| harlowja | from what i remember | 22:48 |
| spandhe | harlowja: hello :) | 22:48 |
| 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:49 |
| 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:51 |
| harlowja | nova afaik injected that password into the disk(s) | 22:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!