[09:28] <nvucinic> hi guys, anyone here? :)  have some questions about cloud-init 
[10:34] <harmw> so, I've specified the EXTERNAL_DHCPC=y thingy in buildroot.config, but it still doesn't execute /sbin/ifupdown
[10:34] <harmw> and calling /sbin/ifupdown directly complains about unknown mappings
[10:34] <harmw> so prhaps I should take the easy route afterall, and just change udhcpc to /sbin/bla :p
[10:41] <nvucinic> helo, i have instaled cloud-init on my centos machine, and i am stuck now. 
[10:42] <nvucinic> it's some strange configuration with centos on hyperv 
[10:42] <harmw> in which way are you stuck :)
[10:42] <nvucinic> is there any chance i could add cloud-init config file over mounted disk  or url ?
[10:42] <nvucinic> well i dont really know what to do now :)
[10:42] <nvucinic> i want to specify configuration to run at machine boot 
[10:42] <nvucinic> one time 
[10:43] <nvucinic> i know what i want in cloud-config and how to define it 
[10:43] <harmw> you have an amazone-like api machine setup?
[10:43] <harmw> like openstack, cloudstack 
[10:43] <nvucinic> i have default installation from yum packet manager on centos
[10:43] <nvucinic> so, that would be - no
[10:43] <harmw> ah
[10:43] <harmw> cloud-init is used to configure cloud images
[10:43] <harmw> and basically, that requirs a metadata service in your network
[10:44] <harmw> - the web url you mentioned
[10:44] <harmw> to download the config from
[10:44] <harmw> usualy lives at http://169.254.169.254/
[10:44] <nvucinic> ah 
[10:44] <nvucinic> ok, is there any way to conigure metadata service only ? 
[10:45] <nvucinic> i deploy instances in "cloud" manner 
[10:45] <nvucinic> hmm... maybe i could get some layer in front of hyperv ?
[10:45] <harmw> just make sure there is a metadata api accessible at that ip, and make sure your vm is able to reach it :)
[10:46] <nvucinic> ok, but how to install // configure metadata api ?
[10:46] <nvucinic> it's part of openstack right ?
[10:46] <harmw> btw, cloud-init can also use configdrive - eg. put the json config on a usb stick (well, image) and add that to the vm
[10:46] <harmw> yea
[10:46] <harmw> or any other cloud platform
[10:47] <harmw> depending on your environment, you could also script something yourself
[10:47] <harmw> afaik, using configdrive would be sufficient for environments that lack a metadata service - like yours
[10:48] <nvucinic> great
[10:49] <harmw> hm, just don't know since whn cloud-init supports it...
[10:49] <nvucinic> this was very helpful 
[10:49] <paresh> hey my cloud-init process is not able to get user-data file on my aws setup
[10:49] <harmw> why not :)
[10:49] <paresh> 2014-02-12 16:16:13,268 - util.py[DEBUG]: Writing to /var/lib/cloud/instances/i-xxxxxxx/user-data.txt - wb: [384] 0 bytes
[10:49] <paresh> it says 0 bytes downloaded
[10:49] <harmw> indeed it does
[10:49] <nvucinic> do i need to setup something extra for configdrive?
[10:50] <harmw> readthdocs.org :)
[10:50] <harmw> about it format
[10:51] <harmw> docs.openstack.org/user-guide/content/config-drive.html
[10:51] <nvucinic> yeah, find it 
[10:51] <harmw> great :)
[10:52] <nvucinic> http://developer.openstack.org/api-ref.htmlext_config_drive.html not working  :|
[10:52] <harmw> paresh: you could try curl on the user-data url from within the instance
[10:53] <harmw> http://docs.openstack.org/user-guide/content/enable_config_drive.html
[10:53] <harmw> nvucinic: I think you should be able to use that
[14:05] <smoser> nvucinic, you can use the 'nocloud' datasource, and 'seed_from' to probably accomplish what you want.
[14:05] <smoser> or you could configure on the disk the url to the ec2 mtadata service and then stand something like that up.
[14:06] <smoser> nvucinic, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config-datasources.txt
[14:06] <smoser> that shows how to configure 'NoCloud' to give it a 'seedfrom'
[14:07] <smoser> then just stand something up there with user-data nd meta-data as described in 
[14:07] <smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/doc/examples/seed/
[14:07] <smoser> you can also pass the seedfrom informatoin on the kernel cmdline if you had easier access to that.
[14:09] <nvucinic> smoser: great, thank you
[15:08] <smoser> harmw, what complains about unknown mappings ?
[15:08] <smoser> your patch surely seemed sane to me.
[16:05] <harmw> nah, forget it :)
[16:05] <harmw> its almost done, Ill push the last bits tonight
[19:37] <harmw> smoser: https://code.launchpad.net/~harmw/cirros/udhcpc-wrapper
[19:38] <harmw> ive had to build this patchd into my updated buildroot env, since thats the one that builds on CentOS
[19:39] <harmw> though it should compile without issues on ubuntu
[19:44] <harmw> so: https://code.launchpad.net/~harmw/cirros/udhcpc-wrapper/+merge/229114
[19:48] <smoser> harmw, seems odd you'd have to set that.
[19:48] <smoser> CONFIG_FEATURE_IFUPDOWN_EXTERNAL_DHCP
[19:48] <smoser> since i thought previously we were running ghrough that code
[19:48] <smoser> in order to get udchpc invoked with the options
[19:51] <harmw> there is a big if EXTERNAL_BLABLA around the part that decides which dhcp client to run
[19:51] <harmw> it's N by default
[20:00] <smoser> so how does udchpc run in 0.3.2 ?
[20:00] <smoser> that seems "external" :)
[20:02] <harmw> please check out static int FAST_FUNC dhcp_up(struct interface_defn_t *ifd, execfn *exec) in ifupdown.c
[20:02] <harmw> it ends with:
[20:02] <harmw> return execute("udhcpc " UDHCPC_CMD_OPTIONS " -p /var/run/udhcpc.%iface%.pid "
[20:03] <harmw> and before that function is the stuff that concerns CONFIGURE_FEATURE_IFUPblablabla
[20:04] <harmw> this all revolvs around L575 :)
[20:12] <smoser> ah. ok.
[20:12] <smoser> i believe you
[20:12] <smoser> :)
[20:16] <smoser> harmw, that looks really nice.
[20:17] <smoser> actually..
[20:17] <smoser> it looks to me like its busted for non-eth0
[20:17] <smoser> as when busybox calls us, it will set that in the environment i presume
[20:17] <smoser> but then you override it by reaading /etc/default/udchppc
[20:17] <smoser> and also i don tlike the global 'DISABLED'
[21:12] <harmw> you dont?
[21:12] <harmw> and that interface... hm, I suppose I shouldve paid a little more attention to that
[21:12] <harmw> ill just remove that from the config file :)
[21:13] <harmw> and disabled as well, if you dont like it
[22:28] <harmw> ah, so
[22:29] <harmw> commnting between watching netflix isn't very wise either :p
[22:29] <harmw> smoser: udhcpc uses eth0 by default
[22:29] <harmw> so using a config file to make it changable for whatever reason shouldn't be a problem
[22:31] <harmw> so, we can configure on which interface we want it to acquire an address
[22:31] <harmw> and udhdpc will in turn set $interface with the interface it got an adress from/on
[22:32] <harmw> http://git.busybox.net/busybox/tree/networking/udhcp/README.udhcpc?h=1_1_stable&id=179f41778880d0a233435f5c9ed04e17316f479a#n73 
[22:34] <harmw> whats wrong with DISABLED, or is there some other easier way of saying 'no, please move on and leave me without an address!'?
[23:47] <smoser> harmw, hm..
[23:47] <smoser> i was thinking when someone types:
[23:47] <smoser>  ifup eth0
[23:47] <smoser> and /etc/networking/interfaces says to bring eth0 up as dhcp
[23:48] <smoser> then 'ifup' invokes cirros-dhcpc
[23:48] <smoser> as:
[23:48] <smoser>   cirros-dhcpc up
[23:48] <smoser> i assumed it somehow conveyed which interface should be brought up
[23:50] <smoser> harmw, yeah, so our command there (line 33 of https://code.launchpad.net/~harmw/cirros/udhcpc-wrapper/+merge/229114)
[23:50] <smoser> needs to :
[23:51] <smoser>  cirros-dhcpc up %iface%
[23:51] <smoser> at least. and can't see why not put in some othe other things avialalbe (like leasetime).
[23:52] <smoser> then, when cirros-dhcpc calls udhcpc it will pass on the provided %iface.
[23:52] <smoser> i suspect then that udhcpc then stuffs that interface into the environment
[23:52] <smoser> and we'll be able to expect it in environment on renew|bound