[08:35] <harmw> ill have a look, thanks
[09:13] <harmw> hm, annoying
[09:14] <harmw> thre is a wrapper to figure what/how to start udhcpc, and then a default.script gets run to actually -do- stuff
[09:26] <harmw> hm, it would be sexy if udhcpc could use the wrapper script itself as a default.script, to keep everything in 1 place (in case we want to add support for another option sometime in the future)
[09:48] <harmw> uhm, that quilt thing isn't able to patch busybox - atleast it doesn't look like it
[11:26] <harmw> smoser: https://code.launchpad.net/~harmw/cirros/udhcpc-wrapper 
[12:47] <fifthecho> Has anyone used fpm to build cloud-init?
[12:51] <fifthecho> Because I'm trying to build current cloud-init packages for older distros (Debian 6, Centos 5) to use on a CloudStack cloud and it's proving quite frustrating.
[13:07] <smoser> fifthecho, no. i dont know fpm.  if you're interested in pursuing that, patches to make it work would be accepted.
[13:07] <smoser> also, there is ./packages/brpm
[13:07] <smoser> but maybe you knew that
[13:35] <fifthecho> Or, is there some repo out there for cloud-init 0.7.5 for older distros?
[13:41] <smoser> what is not functional for older distros? just deps ?
[13:42] <harmw> fifthecho: is there a sane reason to start supporting centos 5 these days?
[13:43] <harmw> given 7 is out
[13:43] <smoser> harmw, so i would have just patched the string 'udhcpc' to invoke udhcpc.cirros instead of udhcpc.
[13:43] <fifthecho> smoser: Older distros have older packages that don't have the CloudStack provider.
[13:43] <smoser> as you have it i think it is a bit recursive
[13:43] <fifthecho> smoser: Unfortunately we have customers who are stuck on old releases.
[13:44] <smoser> fifthecho, right. but why does 0.7.5 not work on older distros. that was the question.
[13:44] <fifthecho> smoser: It should, but there's no packages I can find and I'm having difficulties building RPMs and DEBs as there's no real instructions on how cloud-init builds their packages.
[13:45] <smoser> harmw, ie, i was just oging to do this: http://paste.ubuntu.com/7904991/
[13:45] <smoser> fifthecho, ah. so i'd start either with trunk, using ./packages/brpm
[13:45] <smoser> or updating something in epel or something.
[13:46] <harmw> well, we could've just move /sbin/udhcpc to somewhere else and replace it with the wrapper :p
[13:48] <smoser> correct.
[13:48] <smoser> but i didnt want to do that.
[13:48] <smoser> because then /sbin/udchpc would be the wrapper
[13:48] <harmw> btw your patch keeps feeding udhcpc.cirros with options, wich is not needed anymore either
[13:48] <harmw> yea
[13:49] <smoser> so then when a user invoked udhcpc "manually", they'd get our wrapper. and the wrapper wouldn't know if it was invoked via ifupdown or "upser"
[13:49] <smoser> s/upser/user/
[13:49] <harmw> uhu
[13:49] <smoser> so yeah, if you want you can copy the stanza there
[13:49] <smoser> we can set the options to ""
[13:50] <harmw> well, if were going to patch busybox anyway I'd opt for adding my patch and keep it nice&tidy
[13:50] <harmw> instead of ultimatly defacing udhcpc :p
[13:50] <harmw> (in ifupdown.c that is)
[13:50] <smoser> thats fine.
[13:50] <smoser> but call udhcpc, not 'ifupdown'
[13:51] <smoser> because calling 'ifupdown' is going to call udchpc
[13:51] <smoser> which is going to call ifupdwon
[13:53] <harmw> I dont think I'm following that one, my patch adds a call to /sbin/ifupdown for busybox to execute - that script in turn runs udhcpc, which is calling the same script yet again though with the renew|bound|whatever args
[13:57] <smoser> harmw, you added a entry to ext_dhcp_clients which is part of FEATURE_IFUPDOWN_EXTERNAL_DHCPC
[13:58] <smoser> i had assumed that what that means is that when the user types:
[13:58] <smoser>  ifup
[13:58] <smoser> and the network is ocnfigured for dhcp
[13:58] <smoser> that 'ifup' would then call udhcp (in the current path)
[13:58] <smoser> and instead, your patch is making it call
[13:58] <smoser>  ifupdown up
[13:59] <smoser> which i assumed was basically the same as calling ifup
[13:59] <smoser> which would then run that code again ...
[13:59] <harmw> ah like that, deadlocking
[14:00] <smoser> right. thats how i read it. i could be wrong.
[14:00] <smoser> how does it select an entry to run ?
[14:01] <harmw> either way, there is no ifupdown binary currently - so that atleast shouldn't hurt
[14:01] <harmw> it tries each entry
[14:01] <smoser> ah. based on executable_exists
[14:01] <harmw> indeed
[14:01] <harmw> which is why I just prepended my code to the struct
[14:02] <smoser> ah. ok. so now it makes more sense. i'd leave more of it intact though.
[14:03] <smoser> but you were right in your assesement, that we could just replace /sbin/udhcpc (other than we'd be changing the behavior of that binary by wrapping it)
[14:04] <smoser> harmw, thank you for humoring me.
[14:04] <harmw> humoring? realy
[14:06] <smoser> now i understand much more of your patch
[14:06] <smoser> and it makes a fair amount of sense.
[14:06] <smoser> other than i dont like the name "ifupdown"
[14:06] <harmw> but...
[14:07] <smoser> cirros-dhcp ?
[14:07] <harmw> +c
[14:07] <harmw> or: cirros-dhclient
[14:07] <harmw> anyway
[14:07] <harmw> Ill think of something
[14:07] <smoser> yeah.
[14:07] <harmw> you read the commitmsg btw?
[14:08] <smoser> :)
[14:08] <smoser> no.
[14:08] <smoser> sorry.
[14:08] <harmw> lol
[14:08] <smoser> maybe that would have saved all this, eh?
[14:08] <harmw> only one way to find out
[14:08] <smoser> what about the '-h hostname' -i vendor -I client -l leastime stuff ?
[14:09] <smoser> is that useful to us ?
[14:09] <harmw> havent given that a thought just yet
[14:09] <smoser> i'd think hostname probably is
[14:09] <harmw> my focus was on putting something out there to aid in future enahncements
[14:09] <harmw> to be able to add things like hostname, indeed
[14:10] <smoser> and have no idea what: [[ -h %hostname%]]
[14:10] <smoser> means
[14:10] <harmw> (which is quite sane, for areas without clouds)
[14:10] <harmw> *environments
[14:11] <harmw> anyway, my commitmsg contains a note about beeing able to apply the patch to busybox :p
[14:11] <harmw> which is why I asked if you read it, realy
[14:11] <harmw> :)
[14:57] <smoser> ah. harmw there are ways in buildroot to apply patches
[14:58] <smoser> http://buildroot.uclibc.org/downloads/manual/manual.html#_providing_patches
[19:04] <harmw> haha, not looking into the obvious :p
[19:09] <harmw> oh no wait, my trouble was with busybox
[19:09] <harmw> hm, lets see
[19:10] <aneto> Hello, I am currently having trouble trying to get mounts to work in EC2 with cloud-init 0.7.4 installed from repl my config and logs are https://gist.github.com/anthony-neto/1c522c14ef286646cc9a I having being trying to use a bashton AMI that has a working cloud-init as an example but its a old version of cloud-init, I am going crazy
[19:16] <aneto> If anyone in here is using cloud-init in ec2 with centos, and could gist my a mininmal config to test the mounts I would appreciate it =)
[19:42] <smoser> aneto, so what is that ?
[19:42] <smoser> you want to test mounts. how?
[19:43] <aneto> that gist is what I have been trying, including the log from cloud init, I just want to see cloud-init mount the ephemeral mounts ec2 assigns.
[19:44] <aneto> I have gotten userdata to work, but for the life of me cannot get the swap or ephemeral mounts to work
[19:54] <aneto> I see this in the log, Attempting to determine the real name of ephemeral0 | Mapped metadata name ephemeral0 to /dev/sda2 | did not find entry for sda2 in /sys/block | Ignoring nonexistant default named mount ephemeral0
[20:06] <aneto> smoser, I just want to get the default mounts working for ephemeral0 and swap
[20:08] <smoser> well, built in "should" work.
[20:08] <smoser> it should behave properly with no additional config.
[21:01] <aneto> smoser, if cloud-init doesn't find an entry in /sys/block it ignores the mount?
[21:02] <smoser> i think it does.
[21:02] <smoser> maybe you can say "put it there nayway"
[21:03] <smoser> well, no. it says:
[21:03] <smoser>  http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt
[21:03] <smoser> line 185
[21:03] <smoser> but i think for 'ephemeral0' it has to exist
[21:03] <smoser> and swap too probably
[21:05] <aneto> hmm has this always been the case? I installed an older version of cloud-init and got the mounts to work, however the /sys/block looks exactly the same as the problematic ami
[21:05] <smoser> i dont know . i dont remember to have changed it.