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