=== harlowja is now known as harlowja_away === evilissimo|afk is now known as evilissimo [08:35] ill have a look, thanks [09:13] hm, annoying [09:14] thre is a wrapper to figure what/how to start udhcpc, and then a default.script gets run to actually -do- stuff [09:26] 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] uhm, that quilt thing isn't able to patch busybox - atleast it doesn't look like it [11:26] smoser: https://code.launchpad.net/~harmw/cirros/udhcpc-wrapper [12:47] Has anyone used fpm to build cloud-init? [12:51] 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] fifthecho, no. i dont know fpm. if you're interested in pursuing that, patches to make it work would be accepted. [13:07] also, there is ./packages/brpm [13:07] but maybe you knew that === alexpilotti_ is now known as alexpilotti [13:35] Or, is there some repo out there for cloud-init 0.7.5 for older distros? [13:41] what is not functional for older distros? just deps ? [13:42] fifthecho: is there a sane reason to start supporting centos 5 these days? [13:43] given 7 is out [13:43] harmw, so i would have just patched the string 'udhcpc' to invoke udhcpc.cirros instead of udhcpc. [13:43] smoser: Older distros have older packages that don't have the CloudStack provider. [13:43] as you have it i think it is a bit recursive [13:43] smoser: Unfortunately we have customers who are stuck on old releases. [13:44] fifthecho, right. but why does 0.7.5 not work on older distros. that was the question. [13:44] 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] harmw, ie, i was just oging to do this: http://paste.ubuntu.com/7904991/ [13:45] fifthecho, ah. so i'd start either with trunk, using ./packages/brpm [13:45] or updating something in epel or something. [13:46] well, we could've just move /sbin/udhcpc to somewhere else and replace it with the wrapper :p [13:48] correct. [13:48] but i didnt want to do that. [13:48] because then /sbin/udchpc would be the wrapper [13:48] btw your patch keeps feeding udhcpc.cirros with options, wich is not needed anymore either [13:48] yea [13:49] 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] s/upser/user/ [13:49] uhu [13:49] so yeah, if you want you can copy the stanza there [13:49] we can set the options to "" [13:50] well, if were going to patch busybox anyway I'd opt for adding my patch and keep it nice&tidy [13:50] instead of ultimatly defacing udhcpc :p [13:50] (in ifupdown.c that is) [13:50] thats fine. [13:50] but call udhcpc, not 'ifupdown' [13:51] because calling 'ifupdown' is going to call udchpc [13:51] which is going to call ifupdwon [13:53] 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] harmw, you added a entry to ext_dhcp_clients which is part of FEATURE_IFUPDOWN_EXTERNAL_DHCPC [13:58] i had assumed that what that means is that when the user types: [13:58] ifup [13:58] and the network is ocnfigured for dhcp [13:58] that 'ifup' would then call udhcp (in the current path) [13:58] and instead, your patch is making it call [13:58] ifupdown up [13:59] which i assumed was basically the same as calling ifup [13:59] which would then run that code again ... [13:59] ah like that, deadlocking [14:00] right. thats how i read it. i could be wrong. [14:00] how does it select an entry to run ? [14:01] either way, there is no ifupdown binary currently - so that atleast shouldn't hurt [14:01] it tries each entry [14:01] ah. based on executable_exists [14:01] indeed [14:01] which is why I just prepended my code to the struct [14:02] ah. ok. so now it makes more sense. i'd leave more of it intact though. [14:03] 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] harmw, thank you for humoring me. [14:04] humoring? realy [14:06] now i understand much more of your patch [14:06] and it makes a fair amount of sense. [14:06] other than i dont like the name "ifupdown" [14:06] but... [14:07] cirros-dhcp ? [14:07] +c [14:07] or: cirros-dhclient [14:07] anyway [14:07] Ill think of something [14:07] yeah. [14:07] you read the commitmsg btw? [14:08] :) [14:08] no. [14:08] sorry. [14:08] lol [14:08] maybe that would have saved all this, eh? [14:08] only one way to find out [14:08] what about the '-h hostname' -i vendor -I client -l leastime stuff ? [14:09] is that useful to us ? [14:09] havent given that a thought just yet [14:09] i'd think hostname probably is [14:09] my focus was on putting something out there to aid in future enahncements [14:09] to be able to add things like hostname, indeed [14:10] and have no idea what: [[ -h %hostname%]] [14:10] means [14:10] (which is quite sane, for areas without clouds) [14:10] *environments [14:11] anyway, my commitmsg contains a note about beeing able to apply the patch to busybox :p [14:11] which is why I asked if you read it, realy [14:11] :) === gondoi is now known as zz_gondoi === evilissimo is now known as evilissimo|afk [14:57] ah. harmw there are ways in buildroot to apply patches [14:58] http://buildroot.uclibc.org/downloads/manual/manual.html#_providing_patches === zz_gondoi is now known as gondoi === xmltok_ is now known as xmltok === SpamapS_ is now known as SpamapS === gondoi is now known as zz_gondoi === harlowja_away is now known as harlowja [19:04] haha, not looking into the obvious :p [19:09] oh no wait, my trouble was with busybox [19:09] hm, lets see [19:10] 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] 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 =) === zz_gondoi is now known as gondoi [19:42] aneto, so what is that ? [19:42] you want to test mounts. how? [19:43] 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] I have gotten userdata to work, but for the life of me cannot get the swap or ephemeral mounts to work [19:54] 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] smoser, I just want to get the default mounts working for ephemeral0 and swap [20:08] well, built in "should" work. [20:08] it should behave properly with no additional config. [21:01] smoser, if cloud-init doesn't find an entry in /sys/block it ignores the mount? [21:02] i think it does. [21:02] maybe you can say "put it there nayway" [21:03] well, no. it says: [21:03] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt [21:03] line 185 [21:03] but i think for 'ephemeral0' it has to exist [21:03] and swap too probably [21:05] 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] i dont know . i dont remember to have changed it. === gondoi is now known as zz_gondoi