#cloud-init 2014-07-01 <harlowja> smoser alright, taking another stab @ https://code.launchpad.net/~harlowja/cloud-init/py2-3 (WIP) <smoser> harlowja_away, whoohoo <CatKiller> smoser: I'm nearly done integrating the resize operation. I've wasted most of the time finding a way to compute the size delta thinking that only "+size" operations were supported by qemu-img, not realizing you could simply specify the size by itself... <smoser> :) <CatKiller> smoser: And to do that in bash was really hard :P Since bash doesn't handle floats etc. Well anyways I'll keep this one in my archive as it's full of handy snippets <CatKiller> smoser: The much much simpler version will come soon <smoser> floating point is possible in bash, but can be tricky <smoser> http://smoser.brickies.net/git/?p=snippits.git;a=blob;f=sh/fpdiv;h=7336f6c3b981082b7f8a39e73c0047f10193f303;hb=HEAD <smoser> (if its not obvious, that is floating point division in bash) <smoser> er... actually in posix sh <CatKiller> smoser: Nice, good module actually to keep <harlowja> smoser will do some tests on that, but the basic approach is to start nailing the crap that is changed in 3.x with six usage <harlowja> just gotta hit all the cases (which is hard, ha) <harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/py2-3/+merge/225240 ; hopefully helps get this going <harlowja> the basics at least, doesn't fully work on py3 i think, but a step <harlowja> at least imports all fine under 3.4 (unless i missed a few modules) #cloud-init 2014-07-02 <CatKiller> smoser: Hi Scott, I've got a patch for cloud-image-callback to grow an image <CatKiller> it's fairly simple: if --grow is specified, we try to grow the image first, then when the image is mounted we try to grow the filesystem <CatKiller> (running an fsck right before) <CatKiller> if that's all OK, we continue the script "as usual" <CatKiller> it doesn't support growing raw images and will exit in error if attempted <CatKiller> Do you want me to send you that patch? <CatKiller> smoser: My bad I made a really bad error in it, it's not quite there yet ;) <mnaser> I have added "resize_rootfs: noblock" in my cloud.cfg <mnaser> but it looks like it's still blocking there <mnaser> this is a vm with a 1.2tb disk.. seems like its taking ages to resize <mgagne> mnaser: which OS and which version of cloud-init? <mnaser> mgagne <mnaser> oops early enter <mnaser> el6 + 0.7.4 <mnaser> from epel <mgagne> mnaser: ok, I used to patch cloud-init<0.7.2 to add support for the noblock option. but since you have 0.7.4... it should work <mnaser> mgagne: strange .. because i checked the source of it and it seems there as well.. :\ <mgagne> mnaser: in fact, noblock was broken before 0.7.2: https://github.com/number5/cloud-init/commit/4401877324de10e7d15d9631f9799bfbb54cdf8d#diff-0cbbb4c8c15d47a0e5aebccda88fd9fb <mgagne> mnaser: sorry I can't help you more on that one <mnaser> mgagne: think i found my issue <mnaser> Jul 2 21:45:59 localhost [CLOUDINIT] util.py[WARNING]: Failed forking and calling callback NoneType <mnaser> Jul 2 21:45:59 localhost [CLOUDINIT] util.py[DEBUG]: Failed forking and calling callback NoneType#012Traceback (most recent call last):#012 File "/usr/lib/python2.6/site-packages/cloudinit/util.py", line 220, in fork_cb#012 child_cb(*args)#012TypeError: 'NoneType' object is not callable <mnaser> cloud-init --debug single --name resizefs is failing too, good now i can easily debug #cloud-init 2014-07-03 <mnaser> It looks like cloud-init backgrounded resize is blocking.. and any ideas why it can be taking a really long time? Jul 3 14:43:13 localhost [CLOUDINIT] util.py[DEBUG]: backgrounded Resizing took 275.751 seconds <mnaser> That's from 20G to 160GB (with only ~6GB of data) <mnaser> This is on CentOS 6, upgraded to the latest e2fsprogs <harmw> that kernel doesn't support it, iirc <mnaser> harmw: afaik, there is a feature that makes resizing much faster using lazy_itable_init <harmw> centos' kernel is to old to certain resize things <mnaser> hm. <harmw> i haven't looked at this for say 4 months or so though :) <mnaser> Any suggestions in that case? I rather not drop in a kernel that won't get updated, any "updated centos kernel" repos? <harmw> no no, kernels are holy <mnaser> yeah.. i didn't for a while but we had someone provision a 1.2tb disk centos vm and it's taking forever and a half :) <harmw> perhaps centos-plus, though I doubt even that <harmw> well, why on earth would one require a cloudy instance with 1.2TB of storage? <harmw> :) <harmw> (and ofcourse, 'because one can' is a viable answer :p) <mnaser> harmw: our local disk grows with the amount of memry/etc <mnaser> so this is a 32gb instance <mnaser> ex: 1gb gets 40gb... we grow linearly so 32 ends up with 1280gb <harmw> damn <mnaser> yeah but this isnt too useful if i cant figure out how we can solve this <mnaser> i tried e2fsprogs 1.42.6, 1.42.8 and 1.42.10 (latest) with the utils as well but no go <harmw> on a personal note, since when did there become a direct relation between mem/hdd sizes? :) <harmw> thats not a very good thing imho <mnaser> how come? it helps us not end up with un-used local disk space <harmw> anyway, problem here is resizing takes quite long due to the large disk/fs <mnaser> yeah.. i think it has to do with the old kernel/tooling <harmw> I'm quite positive it was the old (ancient) CentOS kernel in this case <harmw> have you tried ubuntu? <harmw> or fedora? <mnaser> ubuntu boots ultra quick with no problems <harmw> and thats with kernel 3.x? <mnaser> that's why i felt it had to be resize2fs/kernel <mnaser> yup <harmw> yeah, in that case I'm quite positive this boiled down to CentOS' kernel <mnaser> i found this too <mnaser> https://bugs.launchpad.net/bugs/1179610 <harmw> shouldnt take to look for them to set 7.0 free though :) <mnaser> it looks like ubuntu had the same issue in 2013 <harmw> yea, we had this issue with cirros a while back as well <mnaser> it does look like this got fixed by newer e2fsprogs but that didnt help me <harmw> nah, it still requires a shiny 3.x kernel * mnaser sigh <harmw> you might want to give centos7 a try, it's not far from gold status <mnaser> pretty sure the stuff we run on centos 6 hasnt yet been fully prepped for centos 7 <mnaser> http://elrepo.org/tiki/kernel-lt i want to give this a shot <harmw> ah yes <harmw> well good luck <mnaser> harmw: thanks, entering uncharted territory is fun (not) <harmw> hehe <mnaser> i'll let you know though! :) <harmw> yea, I'd appreciate that #cloud-init 2014-07-06 <cloudnoob> is there a good mailing list for cloud-init or is irc preferable? #cloud-init 2014-07-07 <smoser> mnaser, mgagne a couple things: <smoser> a.) kernel resize of online disk is orders of magnitude faster with newer kernels . that got magically fast ~ 3.5 i think. <smoser> b.) backgrounding the resize ends up not being all that useful on the older kernels. It should background, but it is extremely IO intensive and halts most other things. it should work correclty, but everything will be slow. <mnaser> smoser: i notied that, also it doesnt seem like it background cloud-init .. if nothing else in cloud-init is setup to run, it won't really be backgrounded <smoser> it shoudl bacground <smoser> mnaser, is the call to util.fork_cb just broken ? <smoser> it looks right <mnaser> smoser: so what was happening is that it was saying "Backgrounding resize" but it was still blocking <smoser> hm.. i really doubt its broken. <mnaser> and the proof to that even more is that the "part" that does resizing would say "took 180 seonds" let's say and it was blocked there <smoser> hm.. <mnaser> but this is cloud-init of CentOS 6 <mnaser> so maybe that's not been tested <mnaser> also i recall <smoser> i dont know what is in centos 6. i'm just looking at trunk <smoser> but it *is* crazy io intensive <mnaser> there was an error <smoser> and so is boot <smoser> so originally when i did this, i found it to be almost useless. <mnaser> with the callback being a NoneType or something <smoser> hm.. <smoser> let me look at that again <mnaser> also this is 10x ssd drives in raid-10 so it's pretty fast <smoser> you're right <smoser> its busted <mnaser> smoser: Jul 7 12:34:20 localhost [CLOUDINIT] util.py[DEBUG]: backgrounded Resizing took 41.487 seconds <mnaser> Jul 7 12:34:20 localhost [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'init' took 41.799 seconds (41.80) <mnaser> and then it continues afterwards <smoser> :-( <smoser> and i broke it when i added the util.log_ <smoser> open a bug ? <mnaser> perhaps <mnaser> sure <mnaser> smoser: https://bugs.launchpad.net/cloud-init/+bug/1338614 <smoser> mnaser, try: http://paste.ubuntu.com/7760542/ ? <smoser> are you able to easily try that ? <mnaser> hm <mnaser> i think i can spin up a new vm with cloud config disabling resize <mnaser> then patch it and run the module manually <mnaser> i assume if i run it manually it should background as well <mnaser> heck, let me try to patch one that is already running because it's failing to fork resizefs anyways <smoser> it should work, yea. <smoser> mnaser, thank you. <mnaser> smoser: fyi in the cc_resizefs.py file <mnaser> 'args': (resize_cmd, log)) should be 'args': (resize_cmd, log)} <smoser> yeah <mnaser> doesnt give that warning anymore... now to test if it's actually properly backgrounding will take a bit longer <mnaser> but let me do it, solving this will be very usefu <smoser> mnaser, it was calling fork_cb completely wrong. <smoser> so i'm trying to just fix how it calls it, by adding a fork_cb_kwargs and calling that one, and making fork_cb backwards compat and call the fork_cb_kwargs. <smoser> my concern is that fork_cb might not be completley backwards compat <mnaser> and maybe other parts thats rely on it might be broken now <mnaser> right so just made a new vm that was not resized automatically <mnaser> now i'll do the patch for it, delete all the cloud init stuff, reboot and *hopefully* it'll background <mnaser> or should i just run it manually in the shell after patching and it'll be okay, smoser ? <smoser> rm -Rf /var/lib/cloud <smoser> and reboot <smoser> and see <smoser> that'll be more complete at least <smoser> there is only one other caller though <smoser> so i could just patch it too <mnaser> alright so its patched up now <mnaser> rebooting <mnaser> its only going to do a resize from 20gb to 40gb but i think it'll still show <mnaser> oh, it didnt do the resize again beacuse it read the user data (configdrive) and that says not too <mnaser> hm <smoser> ah. rihgt. <smoser> and you can't easily override that. <mnaser> Jul 7 15:22:03 resize-test [CLOUDINIT] cc_resizefs.py[DEBUG]: Skipping module named resizefs, resizing disabled <mnaser> even if i force it to run <mnaser> from the shell <smoser> well if you tell it to run it still reads config <mnaser> i guess what ill do is <mnaser> take a snapshot of this server <mnaser> and boot another one <smoser> mnaser, just put 'resize_root = NOBLOCK' <smoser> right before that <smoser> ie, force it on <smoser> actually.. <mnaser> before where exactly? <smoser> if you run it manually you *should* be able to pass it in <mnaser> cloud-init --debug single -n resizefs <mnaser> this didnt run it manually <smoser> cloud-init --debug single -n resizefs noblock <smoser> try that <mnaser> i'll take a snapshot and boot from it a much larger machien so we have a feel of what it's like <mnaser> so if anything else is disturbing, we'll see it <smoser> mnaser, it is crazy slow. <smoser> i have done resize on spinning disk from 2G to 2TB <mnaser> oh ill make 20G to 80G resize <smoser> and it took > 1 our i think <mnaser> yeah i know that pain :P <smoser> 1 hour <mnaser> ssd, 20G to 1.2TB was 10 minutes <mnaser> still al ot <smoser> yeah. <smoser> and it is crazy magic fast in 3.5 <smoser> its 1000x faster <mnaser> oh well, centos :-( <smoser> yeah <mnaser> alright, got snapshot, booting it now <mnaser> smoser <mnaser> Jul 7 15:31:57 resize-test [CLOUDINIT] util.py[WARNING]: Failed forking and calling callback log_time <mnaser> Jul 7 15:31:57 resize-test [CLOUDINIT] util.py[DEBUG]: Failed forking and calling callback log_time#012Traceback (most recent call last):#012 File "/usr/lib/python2.6/site-packages/cloudinit/util.py", line 224, in fork_cb_kwargs#012 child_cb(*args, **kwargs)#012TypeError: log_time() argument after * must be a sequence, not NoneType <smoser> boo. <smoser> mnaser, http://paste.ubuntu.com/7760686/ <smoser> try that <smoser> and i apologize <smoser> i wondered about that <mnaser> no worries <mnaser> now i can easily rename and reboot :p <mnaser> btw smoser <mnaser> backgrounded Resizing = Backgrounded resizing <mnaser> cannot imagine how much that bothered me in logs :-P <smoser> ? <smoser> oh. i see. capitalize :) <mnaser> yes :p <smoser> well, the 'R' makes sense. <smoser> sort of <smoser> in my world <smoser> as the 'Resizing' in the non-backgrounded path. <mnaser> smoser: really silly <mnaser> but <smoser> (so grepping for 'Resizing' would get either) <mnaser> why not just do this <mnaser> def fork_cb_kwargs(child_cb, args=[], kwargs={}): <smoser> mnaser, generally, http://satyajit.ranjeev.in/2012/01/12/python--dangerous-default-value-as-argument.html <mnaser> aah <mnaser> that's good to know <smoser> https://docs.python.org/2/tutorial/controlflow.html#default-argument-values <mnaser> rebooting <smoser> see the 'important warning' there <mnaser> always learning something new <mnaser> Jul 7 15:48:46 resize-test2 [CLOUDINIT] util.py[WARNING]: Failed forking and calling callback log_time <mnaser> Jul 7 15:48:46 resize-test2 [CLOUDINIT] util.py[DEBUG]: Failed forking and calling callback log_time#012Traceback (most recent call last):#012 File "/usr/lib/python2.6/site-packages/cloudinit/util.py", line 229, in fork_cb_kwargs#012 child_cb(*args, **kwargs)#012 File "/usr/lib/python2.6/site-packages/cloudinit/util.py", line 1830, in log_time#012 ret = func(*args, **kwargs)#012TypeError: 'str' object is not callable <mnaser> smoser ^ <mnaser> tho <mnaser> i think i should ahv esaid this earlier <mnaser> running cloud-init 0.7.4 not trunk <mnaser> so maybe this has to do with it <smoser> mnaser, i'll stop bothering you and i'll just make sure it works on trunk before asking again. <smoser> k? <mnaser> smoser: no problem, thank you so much :) <harlowja> smoser u might want to respond to http://lists.openstack.org/pipermail/openstack-dev/2014-July/039514.html :) <harlowja> see last line ;) <cloudnoob> harlowja: I emailed you about cloud-init-dev over the weekend? <cloudnoob> I will paste my email into irc :) <harlowja> cloudnoob howdy <cloudnoob> It looks like the default configuration of cloud-init on Ubuntu 12.04 LTS causes a new RSA key & fingerprint to be generated when an existing (root) EBS volume is attached to a new instance[1]. I'd like to avoid this behavior on some of my instances. After some poking around, I think removing 'ssh' from cloud_init_modules list in /etc/cloud/cloud.cfg will prevent this from happening[2]. Can a cloud-init-dev@'er confirm this is t <cloudnoob> oh hmmm <cloudnoob> looks like I hit a limit <cloudnoob> 1/ It looks like the default configuration of cloud-init on Ubuntu 12.04 LTS causes a new RSA key & fingerprint to be generated when an existing (root) EBS volume is attached to a new instance <harlowja> that would seem fine to do <cloudnoob> 2/ I'd like to avoid this behavior on some of my instances. <harlowja> take ssh module out <cloudnoob> 3/ After some poking around, I think removing 'ssh' from cloud_init_modules list in /etc/cloud/cloud.cfg will prevent this from happening <cloudnoob> 4/ Can a cloud-init-dev@'er confirm this is the case, and that this is a safe/secure thing to do for existing systems which have already been through once-per-instance setup? I'm also open to advice or suggestions on better approaches. <cloudnoob> see http://serverfault.com/questions/294039/rsa-fingerprint-changed-after-moving-ebs-and-eip-to-new-instance for a similar writeup <cloudnoob> also my understanding is based on the assumption that 'ssh' in this list corresponds to executing the handler defined in 'cc_ssh.py'. <harlowja> cloudnoob i think u can also place ssh_genkeytypes: [] in userdata <harlowja> to avoid it doing any extra key creation <cloudnoob> ok <harlowja> or adjust it in /etc/cloud/cloud.cfg <cloudnoob> is that better than removing from cloud_init_modules? <harlowja> disabling ssh makes it impossible for any user keys to come in, if they ever want <harlowja> i think u are hitting http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/config/cc_ssh.py#L91 which the ssh_genkeytypes: [] should just stop <cloudnoob> ah <harlowja> aka, no more generation, but if people provide them that code path will work <cloudnoob> okay cool <cloudnoob> I'll try it <cloudnoob> there are existing keys so yeah, just don't want to overwrite them <cloudnoob> thanks for the suggestions <harlowja> np <cloudnoob> and thanks for the software of course <cloudnoob> teh useful <harlowja> np <harlowja> thx for using it :-P <smoser> harlowja, thanks for the heads up. responded <harlowja> smoser cool <harlowja> i'm not touching that question ;) <harlowja> u can, haha <harlowja> *not the ipv6 question, the lets get rid of metadata service <harmw> can't we just ditch ip6? <harmw> far easier <harmw> everything just works with ip4 <harmw> lets keep it that way <ijw> yo <ijw> Since I'm here, I wanted to ask: has anyone thought about a generic format for network information (rather than the /etc/network/interfaces file that Openstack likes to template, badly, and then inject)? <harlowja> ijw yes <ijw> How much thinking so far? <harlowja> ijw http://bazaar.launchpad.net/~harlowja/cloud-init/better-todo/view/head:/TODO.rst (this is updated with this, although its been thought of for a long time, ha) <harlowja> smoser u should merge that branch :) <ijw> I have an MTU problem that is really not going to fit in with the current mechanisms <harlowja> ijw i don't think its cloud-init that would have the biggest problem with changing, its the other things that write the format :) <ijw> Win7 doesn't advertise for MTU on DHCP, and Linux has Opinions on how big the MTU can be <harlowja> ijw https://fedorahosted.org/netcf/ has been discussed (although its xml, eck, haha) <ijw> Given that the in-page example is a bridge it's more complex than we strictly need anyway <harlowja> sure <ijw> (also, you can't specify data by eth0/1/2 since they're assigned by the OS) <harlowja> ijw the issue is that other surronding projects need to get away from writing this format also, this imho is the harder part :) <harlowja> *neutron/nova in openstack <harlowja> ijw ideally someone really needs to own that format change and push it through the various openstack projects <harlowja> the cloud-init work i don't think would be that much <harlowja> *at least to do the basics <smoser> harlowja, we have a fail safe datasource. <smoser> ijw, yeah, mtu sucks. <harlowja> smoser damn gotta change that in the todo, no longer a todo then, ha <smoser> ijw, from my perspective, it needs to be specified by the "provider" in one way or another. <ijw> It's not even a format change - it's an additional file on the web server or config drive that could happily be ignored by anything that didn't know about it <smoser> dhcp is reasonable for dhcp . but ideally it'd be available if not dhcp. <harlowja> ijw sure, just write "network.xml" (or something) <ijw> And I think if it had interface, optionally with VLAN/v4(s)/v6(es)/mtu that would be sufficient <smoser> this advertising needs to be more part of the network imo <harlowja> and cloud-init will use it if it exists (or if not look for the old way) <smoser> but maybe not. <smoser> it is very problematic <smoser> and we're hitting it here too. <ijw> smoser: DHCP in either the v4 or v6 forms has various issues advertising MTU. The client needs to know, and v6's spec is written with a pedantic respect to the fact that ethernet doesn't standardise packet sizes >1500 bytes (so making bigger MTUs is hard) <ijw> Assuming YAML wouldn't make people cry, the spec could be very straightforward, in fact * ijw finds an etherpad <harlowja> :), bb, meeting <smoser> it just seems really odd that this isn't sovled <smoser> harlowja, merged. dont say i never did anything for you :) <harlowja> smoser woot :-P <ijw> By sheer coincidence someone's just talked to be about bonding, too... #cloud-init 2014-07-08 <harlowja> smoser what are your thoughts on https://code.launchpad.net/~harlowja/cloud-init/changeable-templates/+merge/208994 (this will help in the py3 update, to have this capability) <harlowja> that combined with https://code.launchpad.net/~harlowja/cloud-init/py2-3 should get most of the issues out of the way <smoser> harlowja_away, oh yeah. forgot about cheetha. <smoser> the stuff there is backward compat ? in taht it will use the old cheetah format if the template doesnt have 'template: foo' ? <mnaser> i'm seeing issues with cloud-initramfs-tools .. more specifically with the dracut module on el7 <mnaser> growpart doesn't seem to run properly.. getting this http://pastebin.com/AH2ftLzX <smoser> mnaser, i suspect you need https://code.launchpad.net/~juergh/cloud-initramfs-tools/dracut-growroot-pre-mount <smoser> personally i thikn the dracut code is racey and broken <mnaser> it looks like it smoser <mnaser> but now im discovering something else <mnaser> you posted this https://lists.fedoraproject.org/pipermail/cloud/2013-May/002405.html <smoser> juerg's solution was to make it happen before the disk is mounted <mnaser> centos 7 comes shipped with 3.10 <mnaser> does that mean i can just use that and forget the dracut stuff? <smoser> mnaser, i think it shoudl work <smoser> yes. <mnaser> will it run a reboot on the machine? <smoser> no. <mnaser> :> <smoser> it uses 'update' <mnaser> the perks of new linux kernels! <mnaser> heh <smoser> kernel in 3.8 now lets you do that. <smoser> yeah. it is really nice. <mnaser> alright so i'm going to remove it <mnaser> and see what happens <smoser> yeah. <smoser> see growpart --help output <smoser> --update <smoser> it shoudl dtrt, but requires partx and 3.8+ kernel. <smoser> i think you can just add '--update=on' and it will fail if it doesn't think it is supported. <mnaser> yep looks like it <mnaser> runs the verify_ stuff <mnaser> alright, this is good stuff, let me clear everything and try this out <mnaser> smoser: woohoo, worked! :-) <mnaser> thank you so much, this is a bit of a relief, making images is annoying! <smoser> i agree making images is annoying <smoser> i rant whenever i can that people shoudln't do it. <mnaser> but there is no centos 7 images <smoser> a sane distribution provider would provide them for you <mnaser> at least not *yet* <smoser> maybe you should chekc the sanity of your distro <smoser> :) <mnaser> haha :p <mnaser> the good thing is they're moving towards making that happen <smoser> cool. i'm honestly ok with other distros. and i do understand that there are lots of reasons why "just use ubuntu" isn't really an option. <smoser> but we really try to make "just use ubuntu" the obvious solution when you say "boy, this could work better". <harlowja> smoser right the idea for https://code.launchpad.net/~harlowja/cloud-init/changeable-templates is that it will work with cheetah or jinja <harlowja> and peopel that will want python3 will really be required to use jinja (since cheetah sorta dead) <smoser> right <smoser> harlowja, good <harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/py2-3 keeps on getting bigger though, lol <harlowja> stupid stuff changes :-P <harlowja> but the only library that doesn't appear on python3 is i believe the oauth one and cheetah <smoser> and oauth is supposed to be dropped anyway <harlowja> kk <harlowja> i don't understand why they moved so many modules around in py3 <harlowja> and then six had to come in and fix that, lol #cloud-init 2014-07-09 <smoser> harlowja, i will take a further look at that stuff on monday <smoser> i'm out the rest of the week. <harlowja> np <harlowja> smoser all good <harlowja> have fun boss sir <harlowja> make sure to leave your basement during vacation #cloud-init 2014-07-10 <linuxgeek_> hey cloud-init <linuxgeek_> i want to use the cloudinit feature, so as a first step i started reading cloudinit on the net <linuxgeek_> got useful info <linuxgeek_> i did a nova boot --flavor x --image xx --userdata /root/test.yaml testvm <linuxgeek_> the content of the test.yaml is copied from here http://cloudinit.readthedocs.org/en/latest/topics/examples.html#run-commands-on-first-boot <linuxgeek_> now i logged into the instance <linuxgeek_> and checked the /etc/hosts file <linuxgeek_> it has not echoed the line <linuxgeek_> any thoughts what i'm missing? <JoshNang> hey, does anyone have time to review a nova spec? we'd like to add a json description of the network interfaces to configdrive/metadata service to make it more flexible. https://review.openstack.org/#/c/85673/ <JoshNang> our use case is baremetal servers (openstack ironic) with bonded interfaces and vlans over those bonds, and be able to support debian/centos/windows more easily. we're more than happy to write the patches to make cloud-init use the new json :) <harlowja> JoshNang i'll look it over <harlowja> linuxgeek_ can u get the cloudinit log file, might have a reason why that didn't happen, /var/log/cloud-init.log (i think) <harlowja> JoshNang on the cloudinit side, what did u think about using to write it in, https://fedorahosted.org/netcf/ ? <harlowja> or other? <harlowja> JoshNang any reason why not just to use that format that netcf takes as input? <JoshNang> harlowja: i figured we'd have to hand code a lot of it. netcf looks like it'd make life a lot easier, at least for fedora/centos/etc, and maybe we can pitch in to help with adding .deb backends <harlowja> damn irc client just crashed, JoshNang what did i miss, think i missed a line <JoshNang> harlowja: openstack in general seems to be trying to moving away from xml. i don't have a strong opinion either way <JoshNang> what you maybe missed: i figured we'd have to hand code a lot of it. netcf looks like it'd make life a lot easier, at least for fedora/centos/etc, and maybe we can pitch in to help with adding .deb backends <harlowja> https://git.fedorahosted.org/cgit/netcf.git/tree/src/drv_debian.c :) <harlowja> might just already work <harlowja> so convert the xml format to json and be done, lol <harlowja> or yaml, or plaintext <harlowja> ha <JoshNang> heh if i have to write a json to netcf gen, i'm sure i can come up with something <JoshNang> plaintext could be fun :) <linuxgeek_> harlowja, i do not find cloudinit directory or clound-init.log. will this be present when the image has cloudinit installed? <harlowja> it should be, u should find a /etc/cloud/cloud.cfg that should have the config, if thats missing then that makes me wonder if cloudinit is installed at all <harlowja> JoshNang anyway, thats just a nitpick, the format as long as its compatible would be great, then can just use netcf (which already seems to do most of what we want) <harlowja> JoshNang when smoser gets back i'm sure he'll have other inputs, he wants to fix some of the current brokenness that is this stuff <JoshNang> harlowja: sweet. i'll review their format and adjust as needed. <JoshNang> harlowja: sounds good! more input is always helpful <harlowja> JoshNang u might be interested in https://bugs.launchpad.net/cloud-init/+bug/1153626 <harlowja> which is where i think smoser wants to go (much more dynamic network config, apparently already done in ec2?) <harlowja> maybe not for your spec, but something to think about <linuxgeek_> i'll upload a ubuntu cloud image since they have cloudinit installed. so the cloud-init.log should have info if its a success or a failure? <harlowja> linuxgeek_ typically yes, if not u can adjust cloud.cfg log levels <JoshNang> harlowja: ooo interesting. i definitely want to see more dynamic network config in openstack (somewhat less useful in baremetal), so if this can help, ++ <harlowja> ya, smoser (i believe on vacation until nexst week?) will have lots to say about that <harlowja> ^ the BDFL of cloudinit, ha <harlowja> i'm just BDFLjr :-P <JoshNang> ahh :) #cloud-init 2014-07-11 <kylestev> why isnât `blkid` mocked? basically, why do I have to run tests as root on debian? ;_; <linuxgeek_> ping <linuxgeek_> !ping <linuxgeek_> hey harlowja_away <linuxgeek_> hi harlowja <harlowja> linuxgeek_ howdy <linuxgeek_> harlowja, fairly well, thanks. <linuxgeek_> re yesterday's thingy on the cloudinit. with a trusty ubuntu cloud image <linuxgeek_> i was able to test the http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config-boot-cmds.txt <linuxgeek_> and it works <harlowja> woot <linuxgeek_> there is another cloud image which is vmdk fedora 19 <harlowja> k <harlowja> that one might not have cloud-init built in, or does it? <linuxgeek_> and that is not able to reach the metadata service url http://(930)970-5854 <linuxgeek_> hence the userdata also does not work <linuxgeek_> how is it that one image works while the other does not <linuxgeek_> is this specific to how the image is built? <linuxgeek_> yes it does have cloud-init in it <linuxgeek_> i can see the cloud directory in /var/lib and cloud-init.log in /var/log <linuxgeek_> so it is a cloud-init enabled image <harlowja> it is likely more how the image was built, what firewall settings (?) could be by default on <harlowja> that should be the only difference really <linuxgeek_> ok <harlowja> and those differences could stop it from contacting 169 <linuxgeek_> is this a internal url? <harlowja> define internal ;) <linuxgeek_> lol :-) <harlowja> its a special IP <linuxgeek_> internal = within the instance and not going outside <harlowja> not usually <harlowja> http://stackoverflow.com/a/7499376 is an idea of what it does <harlowja> but it varies depending on the cloud u are on (the exact details vary) <harlowja> openstack clouds do it differently than amazon and so-on... <harlowja> so its 'special' <linuxgeek_> yes o~s and ec2 is so different <linuxgeek_> and i have o~s based cloud env <linuxgeek_> i read http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html <linuxgeek_> and the stackoverflow post. <linuxgeek_> so it says ec2 knows what instance is making the request and it knows the info abt the instance <harlowja> right, openstack is the same <linuxgeek_> so ec2 can return the metadata that is requested <harlowja> right <linuxgeek_> so this happens even before the request reaches the special ip? <harlowja> right, it happens during vm building time <harlowja> so my guess is if it works for one image and not another, then its an image thign <linuxgeek_> ok <harlowja> thats my gut feeling <harlowja> i'm not sure what the solution is though ;) <linuxgeek_> the flow is, the instance makes a request to the special ip based on the userdata injected to it <harlowja> and before that happens, neutron, nova, make it possible for that special IP to be directed somewhere <linuxgeek_> the openstack sees this request and knows which instance is sending this request <harlowja> ya <harlowja> and sends back some data <harlowja> and that goes through the pipes and pops back up in the instance <harlowja> the instance thinks it talked to a magic 169 address and was none-the-wiser <harlowja> ^ pipe magic <linuxgeek_> is it nova neutron which plays a role in routing the request to the special ip via the nova/neutron security groups and rules? <harlowja> both afaik <linuxgeek_> i'm planning to convert the trusty.img file [which works] to a trusty.vmdk and test <harlowja> i believe nova is the endpoint and has the instance data, neutron sets up the plumbing <harlowja> so both are involved <linuxgeek_> i browsed through the o~s docs and the net too, i did not find details about how nova and neutron play a role in the metadata part. do you happen to know of a doc or a guide which talks about this? <harlowja> i do not, but if u jump in #openstack-neutron channel u might find someone who does <harlowja> there should be something somewhere i would think <linuxgeek_> have u used qemu-img convert? <harlowja> i have <linuxgeek_> sure, i'm on the neutron channel. i'll ask arnd for the docs <linuxgeek_> cool, have u converted a .img file to .vmdk? <harlowja> negative, i haven't touched vmdk stuff :) <harlowja> i have done raw -> qcow2 and qcow2 -> raw <harlowja> but not vmdk stuff <harlowja> linuxgeek_ mestery on the neutron channel should be able to find something <harlowja> i thought arnd was more in glance (maybe different arnaud) <harlowja> or maybe someone else, haha <linuxgeek_> haha, yep sure. #cloud-init 2014-07-12 <harlowja> linuxgeek_ hmmm, no bites on the question in #openstack-neutron, hmmm, maybe next week ? <harlowja> never can tell if people are gonna respond <linuxgeek_> harlowja, yep never can say if ppl will respond <linuxgeek_> hey harlowja_at_home, in continuation of testing different os for cloudinit windows is next in line. <linuxgeek_> i asked this on openstack asking you in case you would know <linuxgeek_> is windows a supported deployment in openstack with esxi hypervisor? <harlowja_at_home> unsure :-/ <harlowja_at_home> i haven't done much with windows, i know some person at yahoo got it running under kvm <harlowja_at_home> openstack + kvm <harlowja_at_home> but likely u want to use https://github.com/cloudbase/cloudbase-init for that <linuxgeek_> yep, Hyper-V, KVM, and XenServer/XCP is in the supported list per the openstack guide <linuxgeek_> there is no reference of esx <harlowja_at_home> ya, i'm not so sure, never done much with esx <linuxgeek_> ok sure, thanks for replying though :-). enjoy the rest of the weekend <harlowja_at_home> np <harlowja_at_home> best of luck :) #cloud-init 2014-07-13 <harlowja_at_home> ijw_, guess u saw https://review.openstack.org/#/c/85673 right? <ijw_> Yup, which I'm pleased to see and commented on <harlowja_at_home> cool <ijw_> He was taking this from the 'fix it in Openstack and they will come' approach but I think mainly cos he didn't know about the cloud-init group <ijw_> Either way, looked pretty okay; could do with a bit of refinement but I think he'll get there <harlowja_at_home> ya JoshNang found this channel (afaik thats the same josh, haha) <ijw_> It's at rev 13 and apparently I'm the only person with a -1 on it, which makes me feel bad, but I still don't think it'll fly in its current form <harlowja_at_home> smoser, when he gets back hopefully has some inputs on it <ijw_> Er, and I note that I was nagging you on there, so not only did I see it, I've been talking to you in the comments ;) <ijw_> (tl;dr: /etc/network/interfaces sucks and we shouldn't use it as a reference form) <harlowja_at_home> :) <harlowja_at_home> i had to write the /etc/network/interfaces translater in cloud-init so i know your pain ;) <harlowja_at_home> ijw_, there i added my comment, better format == good ;) <ijw_> OK, and I've made the comments on routing (which is also throwing /etc/network/interfaces under the bus, but hey) <ijw_> I'm not sure I have a full mental picture of what's needed either, to be honest, I've just noted many weirdnesses of the interfaces format over time, and I'm way out of practice with the redhat way of doing things, which may be precisely the same or completely different (ditto Windows) <harlowja_at_home> eck multicast <harlowja_at_home> multicast bad <harlowja_at_home> * at least yahoo folks that i know say that <harlowja_at_home> forget why they say that though, haha #cloud-init 2014-07-14 <smoser> harlowja_away, ijw i'll read that today. thanks for the link. <harlowja> smoser np boss <JoshNang> harlowja: yup! same josh <harlowja> not the same josh as me, lol <harlowja> why u take my name, lol <JoshNang> it's a good name :D <harlowja> :) <smoser> harlowja, where was your replace-template thing <smoser> neve rmind <harlowja> https://code.launchpad.net/~harlowja/cloud-init/changeable-templates/+merge/208994 <harlowja> smoser how was vacation <harlowja> u get out of basement? <smoser> i did. spent some time in indianapolis and baton rouge. said hello to mike the tiger. :) <harlowja> i only know tony the tiger <harlowja> he makes cereal <smoser> i dont know if they're related. <harlowja> lol <harlowja> could be, cousins maybe #cloud-init 2014-07-15 <harlowja> smoser when u gonna do some taskflow reviews?? ;) <smoser> harlowja, https://twitter.com/jtopper/status/489102959582920704 <smoser> fun <harlowja> lol <harlowja> haters gonna hate <harlowja> i'd be nice to know exactly what he wants in doc <harlowja> instead of just hating <harlowja> but haters gonna hate no matter, lol <harlowja> smoser if i go open up a twitter account and say cloud-init is awesome, will that help :-P <harlowja> cloud-init wishlist: its the best <harmw> lol <harmw> he could've just come here <harmw> tons of nice loving people here <harmw> :p <harlowja> probably stuck in his hating cave <harlowja> can't get out <harlowja> *underground bunker <smoser> debug log is pretty sucky <smoser> we can have our own "read mean tweets" session! <smoser> http://youtu.be/4fB94_DndL8 <harlowja> smoser so the one thing that i can thing that make debug log better is to remove the merging stuff <harlowja> the merging logs <smoser> yeah. ther ei s alot of sutff that could be dropped. or dropped to a SUPER_DEBUG <harlowja> ya, likely just dropped, ha <harlowja> smoser harmw https://code.launchpad.net/~harlowja/cloud-init/less-noise/+merge/226940 <harlowja> thereee <harlowja> removed the top 2 noisy ones <harlowja> mr.twitter guy now can shutup <harlowja> lol #cloud-init 2014-07-16 <harmw> smoser: where is the arm disk image for cirros? <harmw> http://download.cirros-cloud.net/0.3.2/ <harmw> I want to try one before I give my own ARM spins a try <smoser> harmw, there is no disk image <smoser> because hte disk images have grub <smoser> as the only way to boot <smoser> i diont know how to make a image that would boot via a system loader on arm <smoser> ie, we use grub 0.97 for disk images on intel, and the bios will load that. but arm "bios" is either non-existant or widely varied. <smoser> at some point we'll porbably need grub2 in there, to support powerpc <harmw> ah yes, I thought it would go down that road <harmw> perhaps we can use u-boot <harmw> all embedded stuff I know uses uboot <smoser> harlowja_away, https://code.launchpad.net/~harlowja/cloud-init/changeable-templates/+merge/208994 <smoser> harlowja_away, whoohoo. my 1 commit per cycle. <smoser> https://review.openstack.org/#/c/103193/ <smoser> :) <harlowja> smoser not good, u supposed to fix my bug, lol <harlowja> smoser on changeable-templates/+merge/208994, adjusting it <smoser> does it make sense do you think ? <harlowja> i try not to think <harlowja> lol <harlowja> seems to make sense though <harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/changeable-templates/+merge/208994 <harlowja> all updated, bonus points and all <harlowja> crappy renderer included, lol <harlowja> smoser what do i get for the bonus points? <harlowja> a sticker? <smoser> harlowja, you get a free lifetime cirros 0.3 license. <harlowja> :-/ <smoser> unlimited cores <harlowja> hmmm <harlowja> questionable <harlowja> lol <harlowja> i mean, thanks so much <harlowja> jee golly, i'm special <harmw> woooaaa <harmw> smoser: whre do I get a cirros license? <harmw> mine's about to expire... <smoser> fax your request to +1555-cirros0 <harmw> darn <harmw> me don't got no faxin' machine <smoser> hm.. bummer. <harlowja> smoser i tried the number, didn't work <smoser> hm.. <harlowja> smoser another one, just been annoying for my poor 2.6 machine, lol, <harlowja> https://code.launchpad.net/~harlowja/cloud-init/py26-test-fixage/+merge/227098 <smoser> looks good enough. <harlowja> after that i usually only see 1 failure, but its probably cause my base machine is old <harlowja> http://paste.ubuntu.com/7805294/ <harmw> harlowja: sbruno talked to you already? <harlowja> nope <harmw> he apparently did some work on initscripts <harmw> atleast thats what he told me like 2 weeks ago :p <harlowja> cool <harlowja> tell him to get in here then, lol <harmw> he said he'd bug you about it <harlowja> kk <harlowja> smoser harmw when u guys gonna do some taskflow stuff? <harmw> taskflow? <harlowja> no good <harlowja> lol <harlowja> http://docs.openstack.org/developer/taskflow/ <harlowja> my other project <harlowja> https://wiki.openstack.org/wiki/File:Core.png (oh ya) <harmw> +1 for stickman <harlowja> ;) <harlowja> find the happy man <harlowja> extra points if u find him <harlowja> happy stick man <harmw> lol <harmw> specialized worker <harlowja> ha <harlowja> u win cirros free edition <harlowja> for life <harmw> o-m-g <harlowja> ya, i know <harlowja> and u can use taskflow, for life <harmw> the honor <harmw> Ill read this tomorrow <harlowja> cool <harmw> almost midnight here now <harlowja> kk <harmw> bye! <harlowja> lataa #cloud-init 2014-07-17 <mgagne> anyone knows where I could find a backport of cloud-init 0.7.x for Precise? <smoser> mgagne, i've not done one. <smoser> i dont think there are too many issues if you just build trunk <smoser> ./tools/builddeb -us -uc <mgagne> smoser: I'm looking at PPA and looking for a tutorial on how to backport stuff from trusty to precise so I can do it myself <smoser> mgagne, yeah. thats the right path. i' not sure off the top of my head what would be problems. <smoser> i've done that as recently as 0.7.0 <smoser> https://launchpad.net/~maas-maintainers/+archive/ubuntu/maas-ephemeral-images <mgagne> smoser: well, my main challenge is: how do I do this? apt-get source cloud-init on trusty, update changelog to target precise, dput to ppa and hope for the best? <smoser> mgagne, yeah. mostly. you can build it in a sbuild chroot to test locally <smoser> before going to ppa <smoser> (i'd recommend that for quicker turn around) <smoser> but one way or anotehr test it buildling locally before pushing ot a ppa <mgagne> smoser: lets say I have a bunch of dependencies missing that would need to be backported too. How can I programmatically get the list of missing dependencies so I can automate the process? <smoser> you shoudln't have too many dependencies <smoser> for cloud-init ? <mgagne> smoser: yep, it now requires python-json-patch, python-json-pointer and openstack-pkg-tools <smoser> hm.. <smoser> let me see. <mgagne> smoser: it's the first time I create a ppa and backport a package so I'm not familiar with backporting challenges. sorry if I ask a lot of questions =) <smoser> thats ok. <mgagne> smoser: I see backportpackage command exists. Will it take care of dependencies? <smoser> i dont know. i doubt. <smoser> where did youthink you needed openstack-pkg-tools ? <smoser> and python-json-pointer? <mgagne> smoser: this guy thinks he needs it: http://packages.ubuntu.com/source/trusty/python-json-patch <smoser> yeah, you do need that. <mgagne> smoser: python-json-patch needs python-json-pointer <smoser> ah. <smoser> hm.. <mgagne> smoser: so you see the rabbit hole I'm going into <smoser> well, you can probaly fairly easily drop the jsonpatch <smoser> and its not a big deal. <smoser> something i had hoped to develop more <mgagne> smoser: ok, I'll try to drop it. I was hoping to not have to modify debian/control and have to version it somewhere =) <smoser> hm.. <smoser> you'll also have to modify code to do that. i think. not much, it should be contained in <smoser> cloudinit/handlers/cloud_config.py <mgagne> smoser: I just don't understand why python-json-patch needs a run-time dependency on openstack-pkg-tools though <smoser> not runtime <smoser> build time. <smoser> http://paste.ubuntu.com/7810965/ <mgagne> smoser: true, my mistake <mgagne> smoser: will try your patch, thanks <smoser> make test will probably fail too <mgagne> smoser: I guess I can take care of it too <smoser> yeah, or just disable that if it even runs it in the build <smoser> i dont remember <mgagne> smoser: should be trivial to add your patch and disable associated tests, will start with that for now #cloud-init 2014-07-18 <smoser> harlowja_away, when you wake up <smoser> https://code.launchpad.net/~smoser/cloud-init/changeable-templates/+merge/227323 <smoser> you fix that rendering and we're good <smoser> :) <smoser> i'm even fine if you break your more exotic: <smoser> ${hostname} <smoser> style if you support <smoser> $hostname <harlowja> smoser k, so u want $hostname support, i see :-P <harlowja> u no like ${hostname} <harlowja> lol <harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/changeable-templates/+merge/208994 updated with non-brace matching as well <harlowja> sucked over your tests as well <harlowja> smoser an intersting question is that we could change all the existing templates to just use the basic renderer <harlowja> instead of the jinja2 based ones <harlowja> *for the simple ones with 'for' loop like stuff #cloud-init 2014-07-20 <harmw> smoser: regarding https://bugs.launchpad.net/cirros/+bug/1301958 <harmw> I've got a patch ready, just not the infra to test it on :p <harmw> (probably later this week) #cloud-init 2014-07-21 <smoser> harlowja, i'm gonna pull the templates change now <smoser> thanks <harlowja> smoser np boss <harlowja> sounds good <smoser> regarding the default emplater... <smoser> thats interesting thoguht. <smoser> oh. i guess one other thing for the fallback template <smoser> would be to rip out '##" lines <smoser> err. '##' lines <smoser> i think jinja2 makes sense. since resolv.conf does have compex logic in it <smoser> harlowja, one other thing is to replace the build dependency on cheetah <harlowja> hmmmm, ya, replace ye-olde build dependency <harlowja> smoser ya, like most of the template files should be fine with just the crappy templater <harlowja> but can be changed later i guess, if we want <smoser> harlowja, i'd like to have just one renderer used in the shipped templates <smoser> ie, dont want to mix and match there. that just seems unnecessarily complex <smoser> and since the built in wont work for resolv.conf... <harlowja> kk, jinja2 it is then <mwhudson> harmw: hello! <mwhudson> i asked smoser about cirros on arm64 and he implicated you :) <smoser> mwhudson, i have to run, but feel free to update me. <smoser> amd harmw's work may not have been 64 bit. but https://code.launchpad.net/~harmw/cirros/cirros-buildroot-2014.02 might be relevant. <mwhudson> yeah, i think an update to newer versions of things is basically what i want <mwhudson> and while an official release would be nice, anything that behaves a bit more like a regular cloud image than the weird franken-thing i'm currently using would be nice... #cloud-init 2014-07-22 <harmw> mwhudson: that updated buildroot branch is tested on x86_64 only, the arm bits aren't yet in place <harmw> still need to get my ARM device to load up cirros in the first place <Pursuit> anyone have experience with the chef cloud-config module? Having some trouble getting it to run right. the last bit of the traceback is "status, context = matchpathcon(path, mode)#012OSError: [Errno 2] No such file or directory" <smoser> Pursuit, hm.. you can file a bug with info. <mwhudson> harmw: hm, can i help somehow? <mwhudson> harmw: e.g. can you tell me some commands to run that might make something arm64ish? <mwhudson> i find buildroot pretty confusing <mwhudson> smoser: maybe you could talk me through how cirros builds are supposed to work? <smoser> mwhudson, well, to get there you'd have to update the buildroot to newer version <smoser> and then get a config. <mwhudson> smoser: which is what harmw has done i think? <smoser> well, he did update to newer buildroot, yes. <mwhudson> i got it to the point of it asking me _lots_ of questions about the new config yesterday <smoser> i dont know if that has arm64 or not <smoser> https://code.launchpad.net/~smoser/cirros/powerpc <smoser> that has some commits that got powerpc mostly functional <smoser> so you could watch that. <mwhudson> ah ok <mwhudson> smoser: do the config questions require thought or can you just say "no" to almost everything? <smoser> try 'make br-menuconfig' <smoser> switch as few things as you tihnk you can get away with <smoser> to make it 'arm64'y <smoser> and then ... you'll have conf/buildroot-$(ARCH).config <smoser> so ... <smoser> make br-menuconfig ARCH=aarm64 <smoser> i'm not sure whta to call the arch <mwhudson> that says things like <mwhudson> /bin/sh: 1: cannot open /home/mwhudson/canonical/repos/cirros/cirros-buildroot-2014.02/conf/buildroot-arm64.config: No such file <mwhudson> make: *** No rule to make target `/home/mwhudson/canonical/repos/cirros/cirros-buildroot-2014.02/conf/buildroot-arm64.config', needed by `/home/mwhudson/canonical/repos/cirros/cirros-buildroot-2014.02/output/arm64/buildroot/.config'. Stop. <mwhudson> i guess i need to read up on buildroot and stop flailing around <mwhudson> smoser: calling the arch aarm64 would be a good troll :) #cloud-init 2014-07-23 <KaaK> Can I bake some user-data into an image (EC2 AMI) such that I don't have to pass instances user-data when i instantiate them? I.E. does cloud-init also look for configuration on the local machine? If so, where? <KaaK> I'm trying to take as much of the edge off of instantiating images for the rest of my team, and I really only need to take care of a small, unchanging set of cloud-init tasks <guilload> Hi, I experimented a strange bug today with cloud init <guilload> Stdin is redirected to /var/log/cloud-init-output.log via tee <guilload> When using SaltStack salt <guilload> and after a few minutes configuring my machines (AWS Ubuntu 14.04) <guilload> all the processes stop working <guilload> except for "tee" <guilload> which keeps running at 100% <guilload> for 10 long minutes <guilload> and then everything goes normal again <guilload> When I disable the redirection via tee to /var/log/cloud-init-output.log <guilload> It works ok. <CatKiller> smoser: Hi! Sorry I had been sidetracked on adding a "grow" feature to mount-image-callback <smoser> guilload, hm.. <CatKiller> smoser: I've added it (well I've mainly added support to growpart and reuse growpart and resize-part-image from mount-image-callback, but I'm having some issues running chrooted commands using mount-image-callback <smoser> guilload, i've never seen that. but it doesn't seem impossible. <guilload> I've just fixed my problem by redirecting stdout and stderr to /dev/null <agy> i'm adding metadata (not userdata) to an openstack instance that i've created using a config-drive. does cloud-init save this metadata somewhere? all i can find is a pickle file <CatKiller> smoser: I'm just not sure how to run commands, if I follow the example: /mount-image-callback -v trusty-server-cloudimg-amd64-disk1.img -- chroot _MOUNTPOINT_ /bin/sh <CatKiller> and add /mount-image-callback -v trusty-server-cloudimg-amd64-disk1.img -- chroot _MOUNTPOINT_ /bin/sh -c "ls /" <CatKiller> it won't work (it'll complain about "-c") <guilload> but I've taken a look at how the redirection is done to tee and it does look a little clumsy <CatKiller> any idea on how to properly issue the chrooted command? <smoser> agy, no. <smoser> i dont think so. maybe in the pickle. <smoser> but not in a good format. <agy> smoser: ok, that's what i thought. thanks <smoser> the goal is to have have that sort of stuff in /run somewhere <agy> it's in the pickle fwiw <agy> that's where i expected it to be ;-) <smoser> the goal is to put a /run/instance-data.json and /run/instance-data-private.json <smoser> with the -private having things are known priviledged info <agy> that would be ideal <smoser> patches are welcome. <smoser> in fact, you canprobably just ask harlowja_away to do it for you <smoser> :) * agy was waiting for that <agy> ^^ the "patches" comment <smoser> guilload, how clumsy ? <smoser> it might be, but its been used that way for quite a while. the default did change in 14.04 to redirect. but prior to that i always used that output definition and so did many other usres. <smoser> i'm intereted in fixing it. can you file a bug with a reproducible example ? <guilload> yes <guilload> First, I will try to reproduce the bug :) <smoser> CatKiller, hm.. example of chrooted commands issues ? <smoser> CatKiller, hm.. it should be fine like that. <smoser> you do need that '--' but mount-image-callback should respect it. <CatKiller> smoser: Ah I wasn't sure I needed it <CatKiller> smoser: In fact I think it's my bad, I have a 64bit image and I'm on a 32bit system.... <CatKiller> smoser: I should be OK once I get the 32bit one :p <smoser> wow. you have a 32 bit system ? <smoser> is your atari 2600 sitting on top of it ? <CatKiller> smoser: Well in fact it's a 64bit machine I think, but it's one of the first AMD ever produced so it behaves better in 32bit ;) <CatKiller> smoser: But yes
{'channel': 'cloud-init', 'month': 7}