gondoi | utlemming or smoser: you guys around today? | 14:42 |
---|---|---|
smoser | gondoi, here. | 14:51 |
smoser | whats up? | 14:51 |
smoser | gondoi, ^ | 14:58 |
gondoi | smoser, sorry... quick team huddle brb | 14:59 |
gondoi | smoser, okay sorry about that | 15:14 |
gondoi | okay, i am looking for some help with setting up cloud-init the proper way | 15:14 |
gondoi | i'm having trouble finding docs on the config file syntax/options | 15:14 |
gondoi | also, we have images for different distribution releases so versions vary | 15:15 |
smoser | gondoi, well the best documentation on config is doc/example/ | 15:19 |
smoser | and/or the ones that ship in 'config/ | 15:19 |
smoser | ' | 15:19 |
smoser | (in source) | 15:19 |
gondoi | okay, let me look over those | 15:35 |
smoser | gondoi, i'm completley open to improvements in documentation | 15:49 |
smoser | (or code!) | 15:49 |
smoser | :) | 15:49 |
gondoi | smoser, i don't see any examples of /etc/cloud/cloud.cfg, or the files in the .d directory | 16:05 |
gondoi | i'm trying to figure out the best working config for cloud-init itself, not necessarily user-data that it parses | 16:05 |
smoser | they're one and the same. | 16:06 |
gondoi | oh..... | 16:06 |
smoser | see 'config/cloud.cfg' as the one that ships with cloud-init (and config/cloud.cfg.d/05_logging.cfg) | 16:06 |
smoser | thats kind of a design goal of cloud-init | 16:06 |
smoser | whatever you could configure or do when you built the image | 16:06 |
smoser | you can do in user-data | 16:06 |
smoser | and for the most part that is true | 16:07 |
gondoi | smoser, how does backporting work for cloud-init? | 17:17 |
gondoi | for example, i think I found a bug, but if I fix it, i assume it will only land in 0.7.3 and above only | 17:18 |
smoser | gondoi, well for ubuntu, we can get the fix back into 12.04 (or other previous releases) | 17:19 |
smoser | for other distros, whatever their distro policy is. | 17:19 |
gondoi | okay | 17:21 |
gondoi | thanks smoser | 17:21 |
gondoi | i'll get a launchpad issue opened to start with :D | 17:21 |
gondoi | then i'll try my hand at patching it | 17:21 |
harmw | harlowja: I'm reading over the _write_network stuff in distros/rhel.py | 18:17 |
harlowja | yo | 18:17 |
harmw | you still need to fix that? | 18:17 |
harlowja | i'd still like to get to a non-ubuntu input format | 18:17 |
harlowja | i haven't checked the status of netcfg in a while though | 18:18 |
harlowja | *netcf [https://fedorahosted.org/netcf/] | 18:18 |
harmw | ok, well I haven't verified if rhel_util.translate_network() works - my centos6 instance most certainly didn't configure eth0 accordingly so... | 18:18 |
harlowja | oh, it defintly works | 18:19 |
harlowja | at least good enough for y! | 18:19 |
harmw | i thought so, I probably left some required config | 18:20 |
harmw | *out | 18:20 |
harmw | netcf looks nice btw | 18:20 |
harlowja | ya, its a little more distro-independent | 18:24 |
harmw | do you have an example of what cloud-init eventually passes to the translate_network() function? | 18:25 |
harlowja | sure | 18:26 |
harlowja | btw, are u using openstakc or ec2 | 18:27 |
harmw | shouldn't be that hard to convert that debian-style blob to freebsd's /etc/rc.conf | 18:27 |
harmw | my cloud is openstack, though cloud-init says it took the ec2 datasource | 18:27 |
harlowja | k, thats why its not getting called then | 18:27 |
harmw | ah | 18:27 |
harmw | haven't debugged that part just yet, but thanks | 18:28 |
harlowja | the cfgdrive is the main provider of this data | 18:28 |
harlowja | http://paste.ubuntu.com/6515839/ | 18:28 |
harmw | excellent,thanks | 18:28 |
harlowja | http://docs.openstack.org/grizzly/openstack-compute/admin/content//config-drive.html | 18:29 |
harlowja | http://paste.ubuntu.com/6515844/ | 18:29 |
harlowja | from a grizzly instance at y! | 18:29 |
harmw | i've read about configdrive, it looks nice | 18:29 |
harmw | can't cloud-init setup static networking on DHCP nets? | 18:31 |
harlowja | sure, if someone provides it that data | 18:32 |
harlowja | the ec2 datasource afaik doesn't have that data | 18:33 |
harlowja | if it did, then sure, it likely could | 18:33 |
harmw | hm hm | 18:33 |
harmw | ok | 18:33 |
harmw | apply_network() only exists in datasources ConfigDrive, NoCloud and OpenNebula | 18:48 |
harlowja | ya, do u know if the openstack ec2 metadata server even provides it? | 18:53 |
harlowja | i don't recall if it does | 18:53 |
harmw | dont think so | 18:54 |
harmw | well, there is a meta-data/local-ipv4 key | 18:55 |
harlowja | ya, thats not enough afaik to be useable by apply_network | 18:57 |
harmw | nope | 18:57 |
harlowja | i think the openstack ec2 could host network config | 18:57 |
harlowja | i think most people that use the ec2 metatadata sever though use dhcp | 18:58 |
harlowja | *but doesn't mean it has to be that way (of course) | 18:59 |
harmw | yea, and besides, the instance already got all required stuff through dhcp | 19:01 |
harmw | so reading that and writing it to sysconfig would seem viable | 19:01 |
harlowja | depends, the whole 169.blah.blah address stuff imho seems to magical (and hard to debug/reason) | 19:02 |
harlowja | configdrive u know pretty much what the source data was, where it is (via blkid) so it can be easily looked at post-boot... | 19:03 |
harlowja | $ blkid | 19:03 |
harlowja | ... | 19:03 |
harlowja | ex: /dev/vdb: SEC_TYPE="msdos" LABEL="config-2" UUID="124A-8C96" TYPE="vfat" | 19:03 |
harlowja | and the 169 business means u have to run a external service (that can be DOS'd from user vms) | 19:04 |
harlowja | and u have to connect that 169 business via iptables/other | 19:04 |
harmw | true, true | 19:05 |
harlowja | configdrive simpler imho | 19:05 |
harlowja | but to each there own i guess :-P | 19:05 |
harmw | :) | 19:08 |
harmw | hm, can I attach a configdrive to a running vm harlowja ? | 19:12 |
harlowja | not afaik, its created in nova, during the vm creation process, so if it wasn't created during that process, it won't exist | 19:12 |
harlowja | and settings in nova.conf turn it on/off | 19:13 |
harlowja | force_config_drive=true being the main one i think | 19:13 |
harmw | yea, thats to forcefully create a cfgdrive iirc | 19:14 |
harlowja | ya, all controlled by https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2516 afaik | 19:16 |
=== shardy is now known as shardy_afk | ||
smoser | fwiw, i'll be fairly annoying on "change the network interface description code" | 19:22 |
smoser | harlowja, harmw | 19:23 |
smoser | from the openstack side. | 19:23 |
harlowja | agreed | 19:23 |
smoser | i'd accept patches for cloud-init to read one or the other | 19:23 |
harmw | :) | 19:23 |
smoser | but i think it is in general a bad idea to change that on the hypervisor | 19:23 |
smoser | as then you're in a situation where either: | 19:23 |
smoser | a.) you have to know something about the guest in order to know what to provide it | 19:24 |
smoser | b.) you break existing guests | 19:24 |
harmw | agreed | 19:24 |
smoser | wrt config drive... | 19:24 |
smoser | i think looking forward it will go away. | 19:25 |
smoser | i think it was a stop gap solution for a time when quantum wasn't really there and many people had issues getting the metadata service set up correcdtly. | 19:25 |
harlowja | hmmm, idk | 19:25 |
smoser | the dynamic nature of a web service makes it so much more useful. | 19:25 |
smoser | example: | 19:26 |
smoser | https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1153626 | 19:26 |
smoser | ie, on amazon when you attach a new NIC, the metadata service then has information about what the instance should do with that NIC. | 19:26 |
smoser | amazon linux has a tool that then takes the udev event, hits the MD service, and runs 'ifup ethX' appropriately. | 19:27 |
smoser | all making magic work. | 19:27 |
harmw | that sure is nice | 19:27 |
smoser | (good magic in this case ... that can be confusing as other times I complain about magic). | 19:27 |
harmw | :) | 19:27 |
harlowja | ya, its the weird boundary of agents vs init things | 19:28 |
harlowja | *active agents | 19:28 |
harmw | how nice, freebsd respects the rfc in regards to receiving multiple routes through dhcp | 20:28 |
harmw | thus, it just (only) adds the static route to 169.x and not the default route | 20:29 |
=== shardy_afk is now known as shardy | ||
gondoi | smoser, I have a question about the upstart process... on my rackspace cloud server, it appears the nova-agent in use is waiting for cloud-init to finish before configuring netowrking... | 22:35 |
gondoi | this is not good since chef can't be installed at that point | 22:35 |
gondoi | although, I can't find the upstart events that would prevent rc 2 from being fired | 22:36 |
gondoi | do you have a good handle on upstart events and their dependencies? | 22:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!