/srv/irclogs.ubuntu.com/2016/04/04/#cloud-init.txt

=== sterfield_ is now known as sterfield
=== sterfield_ is now known as sterfield
=== sterfield_ is now known as sterfield
=== sterfield_ is now known as sterfield
smoserharmw, around ?16:08
smoserwas looking to merge https://code.launchpad.net/~andatche/cloud-init/freebsd-improvements/+merge/27842716:09
smoserand interested in your thoughts on 'freebsd' ratehr than 'beastie'16:09
Odd_Blokesmoser: 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
rharperOdd_Bloke: no;  we don't have global tags16:30
Odd_Blokerharper: Is that a "not currently" or a "that doesn't fit the model"?16:32
smoserit'd have to be done on the interfaces, there is no global settings.16:33
rharperOdd_Bloke: certainly not currently;  we've not discussed a global apply16:33
smoserit does seem to be an odd ask though16:33
smoser"always use mtu 1400"16:33
rharperheh, openstack does that with ovs16:33
smoserwhere as really it is device (connection) specific16:33
Odd_BlokeWell, if all the network interfaces are going to be virtualised the same, then it doesn't seem super-unreasonable.16:34
Odd_BlokeIt does look like we could do it by editing dhclient.conf though.16:35
Odd_BlokeI _really_ wish there was a dhclient.conf.d.16:35
smoserOdd_Bloke, this is settable in dhcp16:36
smoser option interface-mtu 900016:36
Odd_BlokeYeah, I'm building a test image now, I'll see what MTU it gets by default.16:37
smoserthere were bugs where cirros wasnt respecting that16:38
smoserhttp://www.microhowto.info/howto/change_the_mtu_of_a_network_interface_using_dhcp.html16:38
smoserif 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_BlokeLooking at a leases file on an existing instance, GCE's DHCP server is sending it over.16:40
Odd_BlokeSo hopefully this is all going to Just Work (TM). :p16:40
smoserwell what does it show, Odd_Bloke16:41
smoserifconfig should show the mtu16:41
Odd_Blokesmoser: Oh, right, because cloud-init is wiping away our hard-coded file?16:43
Odd_BlokeSo, 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
smoserOdd_Bloke, right.k i opoened a bug for you on that16:43
smoserhttps://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/156348716:44
Odd_Blokesmoser: Yep, that's what I'm looking at now.16:44
smoserah. and you're assigned :)16:44
Odd_Blokesmoser: ^_^16:44
Odd_BlokeYeah, 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_BlokeBut I was.16:46
Odd_BlokeNext step: enable predictable interface names and see what happens16:46
smoserit "should work", and cloud-init should actually keep you getting the eth0 ones.16:47
smoseryou shoudlt really need to re-build an imae to see immediate fallout16:47
smoserjust remove /etc/udev/rules.d/* and /etc/systemd/network/* and /var/lib/cloud/* and reboot16:47
Odd_Bloke"keep you getting the eth0 ones"?16:49
Odd_Blokes/you/you from/ ?16:49
smoserno. you should get the eth016:49
smoserbut reliably16:49
Odd_BlokeOh, OK.16:49
smoserin that cllud-init writes rules that enforce the macs -> name16:50
smoserbased on the first time that they were seen16:50
smoserso, basically its as if the old  udev persistent naming that autoomatically wrote rules16:50
smoser(without the blacklisting of "virtual" nics)16:50
Odd_Blokesmoser: 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
sputnik13is there any requirement for an ISO configdrive other than the name for the volume?17:36
sputnik13created an ISO with my ssh key like described here https://github.com/kelseyhightower/coreos-vmware-tutorial17:38
sputnik13and ran a ubuntu cloud image under qemu with qemu-system-x86_64 -cdrom <iso> <cloud.img>17:38
sputnik13and the vm comes up and says it can't find any keys17:38
sputnik13but logs do show that the ISO is found and mounted17:39
sputnik13and openstack/latest/user_data is read17:39
* sputnik13 is stumped17:39
cboltwhat does your userdata contain?17:39
sputnik13http://pastebin.com/64EE0VSD17:40
sputnik13essentially17:40
Odd_Blokesmoser: 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
smoserOdd_Bloke, its probably racy17:44
smoseryeah, it is. i'm pretty sure17:44
Odd_Blokesmoser: But it's known to work?17:45
smosermaybe for some things.17:45
smoserbasically have to know more of whats going on there./17:45
smoserand woudl have to think17:45
Odd_Blokesmoser: 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
smoseryou're looking at precise code or trunk code ?17:46
cboltsmoser: when you set network interfaces in metadata, does cloud-init wait until they come up before running the userdata?17:47
Odd_Blokesmoser: precise code.17:47
Odd_Blokesmoser: (Line 397 is the read; line 206 is the write, if you're following along at home)17:50
Odd_Blokesmoser: I'm EOD'ing, so I'll bug you more about this tomorrow. ^_^17:52
smosercbolt, you're asking about config drive ?17:56
cboltnocloud17:56
smoseron xenial,  yes.17:56
smoserit should do the rigth thing17:56
larskssputnik13: 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
bdxsmoser: any idea if cloud-init will support puppet4 (puppet-agent)?19:20
bdxoooh, nm, just found the bug for it19:23
smoserwaldi, around ?19:26
sputnik13larsks did you do that on openstack or straight qemu with an ISO?19:58
larsksThat was qemu + an iso (although I am using the nocloud format for the iso, rather than the openstack format)19:59
larskssputnik13: ^^^19:59
larskssputnik13: specifically, it was this iso image: http://chunk.io/f/ca6ca61dcf29402395c415a3e395e41919:59
sputnik13larsks: thanks, would you mind sharing the qemu options you used?20:00
sputnik13I know this all *should* work, I'm stumped as to what I might be missing20:01
larskswell, 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 102420:01
sputnik13larsks: cool, thank you20:02
sputnik13larsks: 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.html20:44
sputnik13hmm, I wonder why the config-2 thing doesn't work20:44
larskssputnik13: 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
rharpersmoser: http://paste.ubuntu.com/15621102/21:08
rharperubuntu user not in /etc/passwd, so the ssh key add failed (xenial cloud image from 2016-04-03 )21:10
sputnik13larsks no worries, thanks for the hints, I was banging my head against the wall for a couple days21:30
ybathiaharlowja: hi, is the admin_pass feature of cloudinit borken? I see the admin_pass value that I pass during nova boot in metadata.json22:47
ybathiabut it does not seem to work22:47
harlowjaybathia i don't think cloud-init does admin_pass stuff22:47
harlowjathat's more nova file injection22:47
harlowjafrom what i remember22:48
spandheharlowja: hello :)22:48
spandheharlowja: 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 anywhere22:49
harlowjaspandhe  ya, probably look at the 0.7.x branch22:51
spandheharlowja: the method is not there on that branch22:51
harlowjathen, ya, i guessed its not used by cloud-init22:51
harlowjanova 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!