[14:42] <gondoi> utlemming or smoser: you guys around today?
[14:51] <smoser> gondoi, here.
[14:51] <smoser> whats up?
[14:58] <smoser> gondoi, ^
[14:59] <gondoi> smoser, sorry... quick team huddle brb
[15:14] <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:15] <gondoi> also, we have images for different distribution releases so versions vary
[15:19] <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:35] <gondoi> okay, let me look over those
[15:49] <smoser> gondoi, i'm completley open to improvements in documentation
[15:49] <smoser> (or code!)
[15:49] <smoser> :)
[16:05] <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:06] <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:07] <smoser> and for the most part that is true
[17:17] <gondoi> smoser, how does backporting work for cloud-init?
[17:18] <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:19] <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:21] <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
[18:17] <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:18] <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:19] <harlowja> oh, it defintly works
[18:19] <harlowja> at least good enough for y!
[18:20] <harmw> i thought so, I probably left some required config 
[18:20] <harmw> *out
[18:20] <harmw> netcf looks nice btw
[18:24] <harlowja> ya, its a little more distro-independent
[18:25] <harmw> do you have an example of what cloud-init eventually passes to the translate_network() function?
[18:26] <harlowja> sure
[18:27] <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:28] <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:29] <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:31] <harmw> can't cloud-init setup static networking on DHCP nets?
[18:32] <harlowja> sure, if someone provides it that data
[18:33] <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:48] <harmw> apply_network() only exists in datasources ConfigDrive, NoCloud and OpenNebula
[18:53] <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:54] <harmw> dont think so
[18:55] <harmw> well, there is a meta-data/local-ipv4 key
[18:57] <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:58] <harlowja> i think most people that use the ec2 metatadata sever though use dhcp
[18:59] <harlowja> *but doesn't mean it has to be that way (of course)
[19:01] <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:02] <harlowja> depends, the whole 169.blah.blah address stuff imho seems to magical (and hard to debug/reason)
[19:03] <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:04] <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:05] <harmw> true, true
[19:05] <harlowja> configdrive simpler imho
[19:05] <harlowja> but to each there own i guess :-P
[19:08] <harmw> :)
[19:12] <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:13] <harlowja> and settings in nova.conf turn it on/off
[19:13] <harlowja> force_config_drive=true being the main one i think
[19:14] <harmw> yea, thats to forcefully create a cfgdrive iirc
[19:16] <harlowja> ya, all controlled by https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2516 afaik
[19:22] <smoser> fwiw, i'll be fairly annoying on "change the network interface description code"
[19:23] <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:24] <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:25] <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:26] <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:27] <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:28] <harlowja> ya, its the weird boundary of agents vs init things
[19:28] <harlowja> *active agents
[20:28] <harmw> how nice, freebsd respects the rfc in regards to receiving multiple routes through dhcp
[20:29] <harmw> thus, it just (only) adds the static route to 169.x and not the default route
[22:35] <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:36] <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?