#cloud-init 2013-11-01 <Dr_Memory> so once upon a time, I had a multipart mime cloudinit script in ec2 userdata that worked just fine on both lucid and precise: http://pastebin.com/8WPmCmAQ <Dr_Memory> on saucy, however, it appears to do... nothing. <Dr_Memory> the log output on saucy: http://pastebin.com/PY2jeRSk <Dr_Memory> the text/cloud-init section of the mime blob does not seem to have been written out anywhere under /var/lib/cloud, which I'm guessing is the problem? But it's unclear to me why. <Dr_Memory> any pointers, even if to the relevant sections of TFM, would be appreciated. :) * Dr_Memory drops a pin :) <kwadronaut> sssht! in the changelog i see one -maybe- relevant piece touched between precise and saucy, might want to have a closer look at https://bugs.launchpad.net/cloud-init/+bug/1065116 <kwadronaut> this channel isn't very active, btw, patience helps. or a bug, mail, .. <Dr_Memory> kwadronaut: thanks. I realized after pin-dropping that most ppl here were on the plus side of GMT, so I will be patient. :) <Dr_Memory> (also not sure 1065116 is relevant on first blush -- I don't see a KeyError anywhere in cloud-init.log) <kwadronaut> I took that pin and threw it in a haystack. but you're probably right, wrong guess of me. <harlowja> also i think that smoser and i will be travelling soon to, so it might get even more quiet <harlowja> Dr_Memory i'd be useful to know whats in /var/lib/cloud/instances/i-fa2e879e/user-data.txt <harlowja> if u want to share <Dr_Memory> harlowja: just a sec <harlowja> the debug logs look ok, just as u said, not seeing any mime writing really <harlowja> or much other file writing <harlowja> which seems off <smoser> Dr_Memory, it doen't look terribly unreasonable. <Dr_Memory> harlowja: just a sec <Dr_Memory> http://pastebin.com/WwDY5MTZ <Dr_Memory> (I've been fiddling a bit and this is a new instance from the last one I tried, but the behavior has been the same. <Dr_Memory> ) <smoser> user-data.txt.i <Dr_Memory> (possibly of note: there is no newline at the end of the last mime header there?) <Dr_Memory> ls: cannot access /var/lib/cloud/instance/user-data.txt.i: No such file or directory <smoser> Dr_Memory, /var/log/cloud-init.klog <smoser> s/klog/log <harlowja> ya, the full contents of that log file should give us the dirty details <harlowja> *or not so dirty <Dr_Memory> just a sec :) <Dr_Memory> the log: http://pastebin.com/BTjQw2Vg <Dr_Memory> or rather, that's the log from the last reboot -- if you like I can spawn a new instance and get a clean log <Dr_Memory> I tried, in desperation, putting the "cloud_final_modules:" stanza into /etc/cloud/cloud.cfg.d/99_final.cfg (and then rm -rf /var/lib/cloud; reboot), which is why you see it referenced in the logs there. <utlemming> smoser: just pinged you privately <harlowja> np dr. a clean instance log might be the best i think <Dr_Memory> harlowja: figured. on moment, por favor :) <Dr_Memory> (cloudformation is thinking... thinking... thinking...) <harlowja> more thinkin <Dr_Memory> (AWS gears grind slowly, but they grind exceedingly... slow.) <Dr_Memory> okay, virgin log: http://pastebin.com/FrpZp8ir <Dr_Memory> user-data.txt still the same. user-data.txt.i still nonexistent. <harlowja> damn, who put all this merging logs, hahaha <harlowja> :-/ <harlowja> like it seems to be doing stuff <harlowja> is https://org.blank.bootstrap.s3.amazonaws.co ok? <harlowja> not sure what thats supposed to return for u <Dr_Memory> yeah, I can manually grab that URL with curl/wget <Dr_Memory> it returns a #!/bin/sh file <harlowja> k * harlowja scanning codes <Dr_Memory> like so: <Dr_Memory> http://pastebin.com/kififAdN <harlowja> sure <Dr_Memory> huh. I wonder if some library got more strict about certificate alt name validation between precise and saucy? <Dr_Memory> although there's nothing in the cloudinit log to suggest that fetching that url failed <harlowja> ya <harlowja> it seems to have worked, although it didn't write out the right file <harlowja> what does 'ls /var/lib/cloud/instance/' show? <harlowja> or 'find /var/lib/cloud/instance/' <Dr_Memory> holy shit <Dr_Memory> I just s/https/http/ <Dr_Memory> ...and it worked <harlowja> hmmmm <Dr_Memory> *facepalm* <harlowja> if u also try #include-once this will write out a file <harlowja> that file writing should showup in the log <harlowja> just #include just loads it into memory <harlowja> *no log <Dr_Memory> ah, interesting <harlowja> although ssh/not ssh is odd <harlowja> *https/not https <harlowja> (brainfart) <Dr_Memory> well, S3 signed urls are kinda special <Dr_Memory> they end up being https://bucketname.s3.amazonaws.com/ <harlowja> hmmm <Dr_Memory> and if your bucketname has dots in it: https://bucket.name.s3.amazonaws.com/ <Dr_Memory> which doesn't match their wildcard cert <harlowja> hehe, u out of my area of expertise :-P openstack doesn't have these ;) <Dr_Memory> is this worth a bug report? <harlowja> smoser what do u think <Dr_Memory> arguably "don't provide https include urls to sites that don't provide a correct certificate" is a "doctor it hurts when I do this" issue <harlowja> it does seem like odd behavior <Dr_Memory> but the logging could definitely have been better in this case :( <harlowja> def <Dr_Memory> and the behavior is, if not a regression, certainly a change <harlowja> ya, we switched to using the requests library, which is more strict about this stuff <harlowja> although i would have expected some log to <harlowja> i'd be fine with a bug, but smoser might think otherwise <harlowja> http://www.python-requests.org/en/latest/ <smoser> what was the issue there ? <smoser> you effectively had an invalid cert ? <Dr_Memory> smoser: not 100% sure, but when I changed the #include url from https://org.blank.bootstrap.s3.amazon.com/ to http:// suddenly everything just worked. <Dr_Memory> and yes: amazon has a wildcard cert for *.s3.amazonaws.com but wildcard certs AFAIK can't cover sub-subdomains. <smoser> the can i think <smoser> it'd seem like possibly a bug in python-requests <smoser> or possibly its doing the right thing <smoser> i'm not sure. <Dr_Memory> yeah <Dr_Memory> if nothing else, I feel like the log should have told us a bit more about what was going on #cloud-init 2013-11-04 <harlowja> smoser u arrived? <smoser> yeah. <smoser> working on marks keynote. <smoser> fun. <smoser> que pasa senoir? <harlowja> haha <harlowja> well just wanted to say hi and all that crap <harlowja> but not if u working on mr.boss stuff <hltbra> how do I create notifications (email or whatever) if my cloudinit setup fails in Amazon EC2? #cloud-init 2013-11-05 <gondoi> anyone know where boothooks.sh comes from? I don't see it as part of the package, but it's there and trying to run setenforce when selinux is not installed <ypaq> hi <ypaq> i was just trying to deploy a ubuntu node on rackspace with knife. in my bootstrap script i do a noninteractive apt-get update/upgrade. during the upgrade a command line dialog pops up and asks me how i want to proceed with the change of '/etc/cloud/cloud.cfg'. <ypaq> this is a problem since i cannot interact with the shell. is there a way to make cloud init shut-up? <ypaq> i have never used cloud-init before <utlemming> ypaq: https://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt <utlemming> ypaq: let cloud-init handle the update via the #cloud-config directive <utlemming> ypaq: or "export DEBIAN_FRONTEND; apt-get...." <utlemming> ypaq: or "export DEBIAN_FRONTEND=noninteractive; apt-get...." <ypaq> i already do the latter <ypaq> DEBIAN_FRONTEND=noninteractive apt-get -q -y <utlemming> ypaq: did you change /etc/cloud/cloud.cfg? <ypaq> nope.. i didn't even know it existed <utlemming> ypaq: run "apt-get -y install pastebinit; cat /etc/cloud/cloud.cfg | pastebinit"? <utlemming> ypaq: that will give a pastebin of your cloud.cfg...I'm interested in what changed <ypaq> ok... see what i can do <utlemming> ypaq: any luck? <ypaq> it's a dragging process <ypaq> http://paste.ubuntu.com/6367342/ <ypaq> guy from RS support says they are looking into the issue <ypaq> can you tell anything from the pastebin? <utlemming> yeah, RS didn't read the documentation <ypaq> lol <utlemming> its a RS issue. Basically they configured it wrong <ypaq> thanks very much! anything i can tell them? <utlemming> in order to prevent the error, they should be putting local changes in /etc/cloud/cloud.cfg.d/<NUM>_rackspace.cfg instead of change /etc/cloud/cloud.cfg <utlemming> changing that file, which _is_ packaged, will result in errors <utlemming> er, s/errors/config diffs/ on upgrade <ypaq> thanks again! :) <ypaq> i pasted this to RS support <utlemming> ypaq: np...its an easy mistake to make...I did it that way for a while myself <utlemming> ypaq: although, you want to get RS to fix that...because if you accept the package changes then the instance will behave differently than you would expect if you rebundle it. <ypaq> right now i just need to be able to deploy nodes <ypaq> not that i'm going to set up cloud init now <ypaq> RS says i'd have to run my upgrade interactive as workaround.. wtf <utlemming> :| <utlemming> ypaq: which release? <utlemming> ypaq: put "apt-mark hold cloud-init" before you do anything else. That will prevent the cloud-init stuff...but if they have mangled anything else it may not hold. Honestly, they should configure cloud-init with a cfg.d file. <utlemming> s/it may not hold/then other packages may require interactive upgrades/ <ypaq> 12.04 <utlemming> ypaq: yeah, "apt-mark hold cloud-init" should get you through this <ypaq> cool.. trying that <ypaq> one sec <ypaq> excellent.. seems like it made it <utlemming> ypaq: I would recommend removing that once RS gets this straightened out...I'm not a big fan of apt-mark'ing something since you tend to forget about it. <ypaq> thank you very much!! <ypaq> yeah.. makes sense #cloud-init 2013-11-06 <gondoi> utlemming or smoser: you around? * utlemming is here <gondoi> ohai <gondoi> so i'm trying to use config-drive with user-data, but it cloud-init doesn't seem to execute my scripts <utlemming> can you paste your script? <gondoi> i can see that it's getting the file because if i use invalid syntax at the beginning (ala no #!) it errors <gondoi> super simple one just for testing: https://gist.github.com/gondoi/7342051 <utlemming> and /var/log/cloud-init.log <gondoi> umm it's in debug so it has tons of output.. just a min <gondoi> okay, refresh that gist <gondoi> utlemming: any thoughts? <utlemming> gondoi: what cloud is this on? <gondoi> rackspace <utlemming> gondoi: is this from a fresh instance? or have you rebooted it? <gondoi> from a fresh instance <gondoi> i tried putting that script in the user-data <utlemming> is your file in /var/lib/cloud/instance/user-data.txt? <gondoi> yes <utlemming> gondoi: with out taking a look, I'm not exactly sure why its not firing <gondoi> is it a fair simulation to blow away the instances directory and run cloud-init again? <utlemming> gondoi: 12.04? <gondoi> yes <utlemming> rm -rf /var/lib/cloud; cloud-init-cfg start; cloud-init all <utlemming> gondoi: did you do _anything_ else to this instance? <gondoi> i tried copying the original cloud.cfg from the package but i just put back the one from the base image <utlemming> gondoi: do you have launchpad account? <gondoi> eys <gondoi> yes <gondoi> https://launchpad.net/~bkbox <utlemming> can you run "ubuntu-bug cloud-init"? <gondoi> sure <utlemming> and then follow the propmpts. When given a choice with "C", pick that. <utlemming> I forget the prompt <gondoi> cancel? <gondoi> *** It seems you have modified the contents of "/etc/cloud/cloud.cfg". Would you like to add the contents of it to your bug report? <utlemming> Yes <gondoi> oky <gondoi> umm it trashed it.. want me to view or save it for you? <utlemming> gondoi: meh, don't worry <utlemming> gondoi: the problem is here: http://paste.ubuntu.com/6373051/ <utlemming> gondoi: RS has imposed a 13.04 or 13.10 /etc/cloud/cloud.cfg onto 12.04, which is confusing cloud-init. <gondoi> hmm thought about that and tried the 0.6.3 release of the config <gondoi> want to give that one a shot? <utlemming> apt-get -y purge cloud-init; rm -rf /var/lib/cloud /etc/cloud; apt-get update; apt-get -y install cloud-init <utlemming> then "cloud-init-cfg start" and "cloud-init all" <gondoi> bad command all <gondoi> start perhaps? <utlemming> whoops <utlemming> try "cloud-init start" and "cloud-init-cfg all" <gondoi> stil nothing :/ <gondoi> user-data.txt file is there too <utlemming> no, check again <gondoi> oh.. <utlemming> so your problem is that RS has used an improper configuration and that is causing it to crap out on you <gondoi> :( <gondoi> k <utlemming> you are the 2nd person who has been burned by this <gondoi> :D <gondoi> yeah i saw ypaq's messages yesterday I think? wasn't sure if it was the same issue for me <utlemming> I would recommend that you file a support ticket and ask that they use a proper configuration file for cloud-init <utlemming> gondoi: I would be interested to know their response.... <gondoi> me too :D <gondoi> i'll see what I can find out <gondoi> sorry, i'm trying to execute it again so I can reproduceâ¦ i removed the file /var/lib/cloud and ran cloud-init start cloud-init-cfg all and it's not showing now <utlemming> I would run: "cloud-init start", "cloud-init-cfg all", "cloud-init-cfg all final" <gondoi> there we go <gondoi> awesome <gondoi> one more questionâ¦ i noticed you mentioned before that they should use the cfg.d to place the config.. if they put the values there that are in cloud.cfg, will they override the main cloud.cfg? <utlemming> correct <gondoi> cool <utlemming> presidence is /etc/cloud.cfg, /etc/cloud.cfg.d and then your user-data #cloud-init 2013-11-07 <harlowja> smoser https://bugs.launchpad.net/cloud-init/+bug/1248625 <harlowja> "/proc/pid/mountinfo was introduced in linux kernel version 2.6.26" :-/ <harlowja> damn RHEL <harlowja> maybe have to add alternate path for old kernels <harlowja> let me see what i can do #cloud-init 2013-11-08 <gondoi> utlemming: ping #cloud-init 2013-11-14 <harlowja> ok i'm back <harlowja> yaaaaa <harlowja> smoser getting tim the canoncial license stuff <harlowja> have the do a little red-tape to make that possible <harlowja> smoser tim still working through red tape, legal guy is busy today <harlowja> if it takes to long, i'll just submit patch #cloud-init 2013-11-15 <smoser> harlowja, cool. thanks. <harlowja> smoser yt <harlowja> since the legal crap might take a while, https://code.launchpad.net/~harlowja/cloud-init/mtab-fix/+merge/195453 <harlowja> tim might of pissed off the legal guy, lol <harlowja> by saying something like 'why is this taking so long, wtf' <harlowja> if i have to get rid of tim's name there let me know ;) <harlowja> and i'll squish it away #cloud-init 2013-11-17 <harmw> hi guys <harmw> I was wondering if anyone could shed some lights on how a centos6 instance is to configure static networking (based on what it received through dhcp) with cloud-init <harmw> does it require loading specific modules in /etc/cloud/cloud.cfg, or putting specific stuff in cloud-config? #cloud-init 2013-11-18 <nate`> anyone around? <kwadronaut> nate`: best to phrase your question, and not just ask for asking. <nate`> what's wrong with this? http://pastebin.com/PQrZp8R9 <nate`> RHEL uses 0.7.1 for it's cloud init on the RHEL provided AMIs. When using chef: portions from the examples the log dumps out that it can't figure out any cheffyness or puppeteering. <nate`> well other than the -0 that was a typo that I fixed and ran another instance. <nate`> http://pastebin.com/XCz1ndSw is the one without the typos. <nate`> http://pastebin.com/tnBecZk8 is the output of /latest/user-data <nate`> also here's the error when using the chef: directives: http://pastebin.com/gtM22x2R <nate`> Final question someone might answer for me. Is there any decent way to test cloud init scripts without having to fire up a new ami every time? <harmw> cloud-init --bla from inside the instance? <harmw> and rm -rf /var/lib/cloud <nate`> screw it on the using the yaml stuff. shell scripts it is. <harlowja> woot, smoser other branch not needed, tim got approved by legal <swaT30> hey guys, any particular reason that CentOS hosts would be getting a 575.979.1648 route to eth0, while Ubuntu hosts are not? Seems the route breaks metadata on neutron/quantum #cloud-init 2013-11-19 <harlowja> hmmm, i don't know of any reason that would happen swaT30 <harlowja> depends on whats in /etc/sysconfig/network-scripts/ifcfg-eth0 <harlowja> and also what came in on the ec2 metdata/configdrive <swaT30> harlowja: let me take a look at the scripts <swaT30> harlowja: eth0 config script is pretty standard dhcp.. and both instances are getting the same metadata/configdrive info <harlowja> hmmm, not sure then :-/ <harmw> swaT30: an unrelated question, but do your centos instances get configured with static networking? <smoser> nate`, lxc <smoser> http://ubuntu-smoser.blogspot.com/2013/08/lxc-with-fast-cloning-via-overlayfs-and.html <smoser> or kvm <smoser> http://ubuntu-smoser.blogspot.com/2013/02/using-ubuntu-cloud-images-without-cloud.html <nate`> I'm forced into using RHEL because of contractual obligations. <swaT30> harmw: nope, all DHCP <harmw> oh ok <smoser> hey... <smoser> harmw, ping <smoser> harlowja, <smoser> https://bugs.launchpad.net/cloud-init/+bug/1241834 <smoser> can you verify that bug and fix ? <smoser> i'll yank that. <smoser> wanting to do 0.7.4 <smoser> and that looked reasonable if it "works and fixes" for you. <harmw> sup smoser <harmw> don't tell me you tabcompleted the wrong person :p <smoser> i did. <smoser> yeah, sorry. <harmw> np :) <harlowja> hey smoser , just got in, will verify that <smoser> i think the issue is just that 0.6.4 is listed there. <smoser> and there is no tag <smoser> ie, i think this: http://paste.ubuntu.com/6444094/ <smoser> i can see the failure without it <harlowja> ah <harlowja> hmmm <harlowja> let me try that out <smoser> harlowja, i just pushed up a fix. just joined 0.6.4 into 0.7.0 (which is actually "correct") <harlowja> kkk <harlowja> was just about to try it out :) <smoser> and now 'make rpm' fails for me with command not found on 'rpmbuild' <smoser> (which is compltely reasonable) <harlowja> :) <harlowja> i'll double check, getting bugged to review some stuff <harlowja> i've been neglecting some internal reviews, haha <smoser> harlowja, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1250398 <smoser> very tempted to drop boto requirement <harlowja> botooo <harlowja> oooo <harlowja> that code still exists somewhere i think <utlemming> smoser: also, boto is now maintained by AWS <harlowja> intersting it is utlemming <harlowja> was there a public announcement about that? <utlemming> harlowja: I don't think so. Mitch went to work for AWS a while back. The new EC2 CLI python tool is based on Boto. <harlowja> ah <utlemming> https://aws.amazon.com/sdkforpython/ <harlowja> so by inference its supported by amazon then :) <utlemming> well, that last link is about as official as AWS can get on that <harlowja> but that seems like they are replacing boto -> boto3? <harlowja> https://github.com/boto/boto3 <utlemming> that's news to me.... <harlowja> "This is not a port of boto, but a ground-up rewrite." <utlemming> (admittately I don't follow boto closely) <harlowja> *from readme.rst there <harlowja> np <harlowja> good to know anyway (i didn't know it either) <utlemming> at least it is a MIT license....with AWS you never know what you'll get <harlowja> smoser on a RHEL 6.4 box, http://paste.ubuntu.com/6445336/, all seems ok <harlowja> *on a fresh VM/box <harlowja> seems ok to me #cloud-init 2013-11-20 <smoser> thanks harlowja . <harlowja> np <smoser> did you see my release of 0.7.4 ? <harlowja> ya <harlowja> thx! hopefully internally people can pick that up and bundle it in <smoser> yeah. and hopefully RH folk could grab it. <harlowja> def <smoser> https://bugs.launchpad.net/cloud-init/+bug/1220461 <smoser> ? <harlowja> whats that about, ha <harlowja> so little context, ha <harlowja> :-/ <harlowja> that almost seems like a savannah bug? <harlowja> but i'm not sure <harlowja> *openstack savanna (which the bug poster is part of) <harlowja> maybe it got assigned wrong or something #cloud-init 2013-11-21 <eric0> hi all <eric0> is there a way to use ec2 metadata in cloud-config actions? i read the docs on datasources but don't understand whether it automatically pulls down all the stuff available in /latest for use somehow, or whether i need to shell out to ec2-metadata or curl to make use of it <smoser> no. its not readily available, eric0 <eric0> ok i'll just use a little shell snippet, thx. poking at some additional puppet integrations with it and puppet's trained me too well to treat shell as the last resort :) <abk> ping... can anyone here answer what all distros compatibility does cloud-init already has... or point to a resource which does <kwadronaut> http://cloudinit.readthedocs.org/en/latest/topics/availability.html?highlight=centos <kwadronaut> ignore the highlight. <abk> thanks <abk> I'm trying to get clear picture around cloud-init... using it with lxc or virtualbox containers shall work as with any advance hypervisor-based containers right <smoser> you needto give it a datasource. <smoser> but yes. <abk> ok, and the link says "and more..."; I'll specify the other distros than listed which are of my concers... please let me know if any of those are not supported... Gentoo, Arch, OpenSuse, FreeBSD <abk> and also is there any tutorial (getting started like) to tryout these on lxc or virtualbox <kwadronaut> hmmm if there aren't any hello world examples, looking at the cloud config examples could get you started. <kwadronaut> i remember that around may someone said he wanted to start hacking on fbsd support, don't know the current status. <abk> thanks, any ack on Gentoo/Arch/Suse <kwadronaut> i don't personally use any of those. you might want to try the mailinglist or something like that. or stick around for a longer time until someone else pops by who happens to know answers. <abk> kwadronaut, sure... thanks... just one more Q. do you have any reference links for creating a cloud-init enabled (cloud) image... or to re-phrase it how cloud-images fetch for user data <Chocobo> Does the "user: <USERNAME>" configuration option create <USERNAME> or does it already have to exist? <Chocobo> Nevermind... I found it in the examples <Chocobo> errr.. I found "users:" not "user:" <abk> ny reference links for creating a cloud-init enabled (cloud) image... or to re-phrase it how cloud-images fetch for user data? <Chocobo> is it lock_passwd or lock-passwd? The example has it both ways. <harlowja> smoser woah, just noticed that http://cloudinit.readthedocs.org/ format changed <harlowja> did u do that, or was that the readthedocs.org people <smoser> i think that was rtd <smoser> i didn't do it <smoser> hm.. <smoser> look at the bottom 'latest' (for versions) <smoser> i wonder if there is more on that. <smoser> as that is something people have asked for. <smoser> (of cloud-init, version specific doc) <harlowja> ya, remember how i think i found a link that version support for bzr not so good :-/ <harlowja> http://read-the-docs.readthedocs.org/en/latest/features.html#versions <harlowja> i think cloud-init uses tags, not branches <harlowja> which is under [No <harlowja> if u created fake-branch that might make a version appear (not sure really) <smoser> hm.. yeah. <harmw> looking fine, that new page <harlowja> ya, the search is neat <harlowja> versions would be nice to (but see above) <harmw> yea, im kinda missing a changelog <harlowja> agreed <harlowja> we can probably plug that in pretty easily <harlowja> weird smoser , http://anvil.readthedocs.org/en/latest/ didn't get updated <harmw> plus, is it just the look&feel thats changed or did the docs themselves got refreshed aswell? <harlowja> look & feel afaik <harmw> k <harlowja> although its odd that my other rtd site didn't change <harmw> job wel done i'd say :) <harlowja> maybe they are selectively rolling out that upgrade <abk> if I need to make a particular distro cloud-init ready... what are the steps... are Gentoo/FreeBSD/Suse supported <harlowja> freebsd is the odd one there :-P <harlowja> 1. make sure python exists in distro <harlowja> 2. make sure basic cloud-init works there (likely remove most of the modules that run) <harlowja> 3. figure out how cloud-init will get started on boot <harlowja> 4. adjust any code in cloud-init (especially for freebsd) <harlowja> - repeat 2 -> 4 <harlowja> 5. package cloud-init for distro <harlowja> 6. profit <smoser> 7. share profit with poor smoser <abk> @harlowja, @smoser thanks :) ...my main confusion is how system knows to run cloud-init as prior boot task before any, is there any article/wiki from Ubuntu Cloud Images or others that I can refer <harlowja> hmmm <harlowja> its very system specific unfortunately abk <harlowja> each system uses somethign different <harlowja> systemd upstart sysvinit <harlowja> ... <harlowja> upstart -> ubuntu <harlowja> systemd -> fedora <harlowja> sysvinit -> most everything else (old school) <harlowja> freebsd -> (??) <smoser> abk, the big thing is that cloud-init local runs first, then cloud-init network (and that should run only after all networking has come up) <abk> openrc -> freebsd <smoser> and then the same order for the other upstart/ jobs. <harlowja> ya, what smoser said is the big ordering <abk> if I can clealry understand application of it in terms of any sysVinit/systemD/upstart/openrc; I'll decipher it for others :( <harlowja> abk u can look at the upstart/sysvinit and such in http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/sysvinit/redhat/cloud-init <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/upstart/ <abk> ohk, thanks <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/systemd/ :) <harlowja> bb <abk> hopefully if I get it going... I'll publish article so I don't forget and come asking and others can refer :D thanks folks <smoser> abk, that'd be great. <smoser> there are certainly some linux-isms there. <smoser> but we're open to finding more cross platform solutions. #cloud-init 2013-11-24 <harmw> are there plans to have cloud-init run on freebsd? <harmw> hm, I'm guessing a freebsd.py in cloudinit/distros could suffice... #cloud-init 2013-11-25 <smoser> harmw, i'd be open to that. <smoser> i suspect that you'd run accross some linux-isms. <harmw> yea <harmw> python-jsonpatch is missing from freebsd10 repo, but the others are there (beeing cheetah, prettytable and some more) <harmw> there are some tiny differences though, like files from /proc <harmw> like, if I run cloud-init it isn't capable of reading system uptime <harmw> or showing assigned ip addresses <harmw> and ofcourse a proper module to handle configuration is needed :) <harmw> (distro) <smoser> harmw, yeah. i'm sure there are things to fix. python-jsonpatch can probably be made optional, and just fail/warn if the user tries to use it. <harlowja> cheetah is a problem that we need to work out anyway harmw <harlowja> unsure what is the best way forward there (cheetah and python 3 still not behaving nicely afaik) <harmw> ah ok, well ive tried cloud-init with python27 on freebsd 10 beta3 <harmw> as far as python's concerned, it looks to be ok <harlowja> cool <harlowja> the other area u'll hit i think is utils.py <harmw> probably <harlowja> unsure how much there will need to be adjusted for freebsd <harmw> not sure on that, I merely deployed cloud-init to see if it would run - which it did <harmw> now all I need is some time to dig further :) <harlowja> :) <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/util.py <harlowja> for example, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/util.py#L1009 <harlowja> and other ones that might be mostly linux specific <harmw> smoser: any chance this cirros patch can be included in trunk? https://bugs.launchpad.net/cirros/+bug/1190372 <harmw> (and the fix from https://bugs.launchpad.net/cirros/+bug/1132686 aswell) <smoser> harmw, whoot. thats awesome. <smoser> thank you. <harmw> :) <smoser> other than i'd bikeshed on your shell. <smoser> but i'd just never looked into it. <smoser> what is the content of a 'staticroutes' ? <harmw> let me check on that <smoser> oh. i see . it looks like it must be pairs of (<netaddr>, <router>) <harmw> 575.979.1648/32 575.979.1648 <harmw> there <harmw> thats in $staticroutes <harmw> took a while to create a new instance, my cloud isn't that fast :) <smoser> harmw, could you test default.script at <smoser> http://paste.ubuntu.com/6475373/ <smoser> that should cut down on forks for parsing output (echo $.. | cut) <harmw> ah yea <smoser> i know i over-do things <harmw> nice function <smoser> but i want cirros to boot as fast as possible <smoser> and forks *do* have a real affect on that. <harmw> hehe <harmw> let me check it <harmw> jeez, downloading plain requires a login <smoser> yeah, silly. <smoser> here, harmw http://paste.ubuntu.com/6475388/ <smoser> that is how to avoid logging in to ubuntu pastebin <harmw> Lease of 575.979.1648 obtained, lease time 120 <harmw> deleting routers <harmw> adding dns 575.979.1648 <harmw> adding net 575.979.1648/32 with router 575.979.1648 <harmw> looking just fine <smoser> cool. i'll apply that then. thanks!. <smoser> all, <smoser> https://ch.tbe.taleo.net/CH03/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=727 <smoser> https://ch.tbe.taleo.net/CH03/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=727 <smoser> first is SW Engineer, second is QA Engineer (both at Canonical). <harmw> North America... kinda far, far away :) <harmw> nice work @r284 <harmw> could you check up on the other bug aswell smoser? If time permits, ofc <smoser> harmw, probably not a requirement <smoser> (the location) <smoser> what other bug ? <harmw> https://bugs.launchpad.net/cirros/+bug/1132686 <smoser> harmw, can you verify <smoser> http://paste.ubuntu.com/6475825/ <harmw> sure <harmw> excellent <harmw> interesting, my freebsd instance only configured the additional host route - not the gateway <smoser> wait, what ? <harmw> no, nothing cloudinit just yet <harmw> merely booting an image, nothing fancy :) <smoser> AH. K. <smoser> did the cirros change work ? <smoser> i'll push that to trunk. <harmw> yea <smoser> thats what you get for not testing <smoser> s/you/i/ <harmw> it looks fine here <harmw> nice @r285 <smoser> harmw, thanks for your help. <harmw> np #cloud-init 2013-11-30 <mushtar> does cloud-init work with yum? <harmw> sure, it uses yum to install additional packages #cloud-init 2014-11-02 <harlowja> smoser u make it? <smoser> i'm in the paris. <smoser> hyatt. <smoser> you? <harlowja> ya, same hotel <harlowja> tired as heck though, so probably gonna go take a nap, lol <harlowja> damn long flight :-P * smoser came direct from detroit <harlowja> lucky u, ha <smoser> there are advantages to living in a hub. <smoser> slept probably 5 hours of 8 hour plane ride. feeling tired enough to hopefully sleep tonight. <harlowja> woot <harlowja> alright, bbl, maybe meetup later or something #cloud-init 2014-11-03 <harlowja> smoser where u <harlowja> this is zzzzz (keynote, lol) #cloud-init 2014-11-04 <smoser> JayF, you in paris ? <mhroncok> hi, any chance https://code.launchpad.net/~harlowja/cloud-init/py2-3/+merge/225240 will be merged soon? <smoser> harlowja, https://github.com/dprince/os-net-config/tree/master/etc/os-net-config/samples <harlowja> smoser https://github.com/dprince/os-net-config/blob/master/os_net_config/objects.py#L136 <harlowja> seems like the implemnetations convert down those objects into different formats <harlowja> and thats it; read from yaml/json, make objects, write objects using different formatters <harlowja> and run some restart commands <harlowja> ifup/down... <harlowja> although i like templates and not big string functions :-P <harlowja> * https://github.com/dprince/os-net-config/blob/master/os_net_config/impl_ifcfg.py#L73 #cloud-init 2014-11-05 <harmw> hiren_: did you checkout the new cloudinit pkg on fbsd? <harmw> it installed and ran just fine a few days ago, absolutely wicked stuff :) <hiren_> harmw: heh, not my self but it's being integrated in freebsd release process right now :-) <hiren_> I mean, right now now. <smoser> hiren_, you have a link to something i could read on "its being integrated in .." <hiren_> smoser: it's all in testing phase so I am a bit hesitant but... https://svnweb.freebsd.org/base/projects/release-vmimage/release/amd64/mk-openstack.sh?view=markup&pathrev=274133 <hiren_> I'd want it to get into the final/good shape before announcing anything. <gholms> Fancy <smoser> hiren_, thanks. <hiren_> sure. <hiren_> you'll are at the conf right now? <smoser> gholms, i ran into nurmi here. <smoser> i'm here in paris, so is harlowja. <gholms> Excellent. <gholms> Did you run across grze as well? <smoser> i told him you should have gotten to come <smoser> not seen grze. <smoser> chris (dont remember last name) and one other guy.. <smoser> they gave me a cab ride from airport <gholms> Was his last name Grzegorczyk? :) <harmw> hiren_: thats some nice stuff you have there <harmw> hiren_: https://github.com/clalancette/oz/blob/master/oz/auto/FreeBSD10.0.auto <harmw> perhaps that's got some usefull stuff as well <smoser> gholms, yeah, i think so. <gholms> That'd be grze. <smoser> oh. hm.. then i confused him (or the namek 'grze') with grazziano (sp?) <gholms> Ah, could be. He's obino on IRC. <smoser> yeah. thats right. #cloud-init 2014-11-06 <fmoreau> hi, sorry for the dumb question, but how can I disable datasource fetching, or in other words how can I set cloud-init to use empty datasource only ? thanks. #cloud-init 2014-11-07 <fmoreau> hi, how can I disable datasource fetching entirely ? <harlowja> smoser u are leaving today right? <smoser> yeah <smoser> on a bus at 10:50 <harlowja> kk <harlowja> well it was fun smoser <harlowja> ha <smoser> harlowja, yeah. nice to see you man. <harlowja> def :-P <fmoreau> hi, is package_command() really needed, or simply implementing update_packages_sources() and install_pakages is enough ? <wumpus42> I have been successfully using cloud-init 0.7.4 in a centos 6.5 image I created under an icehouse environment. When I created a new centos 6.5 image and yum installed cloud-init, I got 0.7.5. 0.7.5 is failing in setting up the ssh keys for the user. <wumpus42> I turned up/on DEBUG for cloud-init console logging <wumpus42> Here's the contents of /var/log/cloud-init-output.log http://pastebin.ubuntu.com/8869675/ <wumpus42> ok. wait. something's funky about that pastebin. let me try again <wumpus42> http://pastebin.ubuntu.com/8869713/ <wumpus42> line 683 seems to show the error. Does cloud-init 0.7.5 work with icehouse? does it need a particular patch to icehouse? <wumpus42> it seems that the error is occurring in /usr/lib/python2.6/site-packages/cloudinit/ssh_util.py while trying to parse through /etc/ssh/sshd_config <wumpus42> I have been successfully using cloud-init 0.7.4 in a centos 6.5 image I created under an icehouse environment we're running in a lab. When I created a new centos 6.5 image and yum installed cloud-init, I got 0.7.5. 0.7.5 is failing in places 0.7.4 wasn't like setting up the ssh keys for the user. I turned up/on DEBUG for cloud-init console logging. Here's /var/log/cloud-init-output.log... <wumpus42> ...http://pastebin.ubuntu.com/8869713/ . If I'm reading the source correctly, line 683 of /usr/lib/python2.6/site-packages/cloudinit/ssh_util.py seems to be having a problem while trying to parse through /etc/ssh/sshd_config. #cloud-init 2014-11-10 <smoser> o. #cloud-init 2014-11-11 <spandhe> Hi everyone! <spandhe> qq.. does cloud-init support IPv6? <smoser> spandhe, "sort of". <smoser> if you're not feeding networking in via confdig-drive or something then really thats just a matter of the image config. <spandhe> I am using config drive <smoser> and inserting a /etc/network/interfaces ? <smoser> it could work. there might be some issues with ubuntu images. <smoser> but largely if /etc/network/interfaces is going to come up fine, then that should work. <smoser> MAAS is using cloud-init in ipv6 only scenarios. <spandhe> one odd thing I observed is, inside the disk. cat /etc/sysconfig/network doesnt say networking_ipv6=yes <smoser> so it is possible. <smoser> then that (sysconfig) probably needs some work for it. <smoser> it is work that needs to be done "really soon now". <spandhe> I see that /sysconfig/network-scripts/ifcfg-eth0 has the right info.. but probably because ipv6 is disab;ed in network file, network config is not happening correctly.. <spandhe> smoser: is that something to be done on cloudinit side or nova side? <smoser> spandhe, well, that is probably cloud-init reading a /etc/network/interfaces style file provided to it by nova/neutron <smoser> and rendering it. <smoser> to sysconfig style <smoser> the going-forward plan for this is to have a better declaration format for netwroking <smoser> than "/etc/network/interfaces". <smoser> https://review.openstack.org/#/c/85673/13/specs/juno/metadata-service-network-info.rst <spandhe> smoser: can u point me to the code where this rendoring happens? <smoser> probably in cloudinit/distros/rhel.py <spandhe> smoser: thanks! :) I found https://github.com/number5/cloud-init/blob/master/cloudinit/distros/rhel.py#L94-L98 <spandhe> doesnt seem to do NETWORKING_IPV6=Yes <spandhe> smoser: adding NETWORKING_IPV6=yes seems to help.. should I open a bug? <smoser> spandhe, sure. #cloud-init 2014-11-12 <spandhe> smoser: looking further, need a few more things.. <spandhe> smoser: the network-scripts file should have the following format: http://www.cyberciti.biz/faq/rhel-redhat-fedora-centos-ipv6-network-configuration/ <spandhe> Therers âIPV6â prefix, which is currently missing #cloud-init 2014-11-13 <Wumpus42> question about /etc/cloud/cloud.cfg. How does One determine into which "section" (cloud_init_modules, cloud_config_modules or cloud_final_modules) to put a module? I wanted to try out the resolv-conf module, but it wasn't listed in the default /etc/cloud/cloud.cfg created by the yum install of cloud-init. <Wumpus42> I tried it in cloud_config_modules:, then just before final-message in cloud_final_modules, which seemed to work. Is the intent that you can put any of the modules in any of the sections? Or are they intended to be part of just a particular section? <Wumpus42> Also: Is order important? Does where you put the module in the .cfg file affect when it's "run"? <Wumpus42> over :) <Wumpus42> Umm... another also: The example at http://cloudinit.readthedocs.org/en/latest/topics/examples.html#configure-an-instances-resolv-conf seems to be wrong (for 0.7.5 anyway). It should be "manage_resolv_conf: true" not "manage-resolv-conf: true" <smoser> Wumpus42, order is important. <smoser> and some modules wont mnatter where you put them, but others would need to be run sooner or later. <smoser> Wumpus42, you're probably right about that dock. <smoser> :-( <Wumpus42> but they do get "run" in the order in which they are in their section? <Wumpus42> thanks for the feedback. is the doc error a bug report? I didn't see anything on the page itself that lent itself to feedback #cloud-init 2014-11-14 <Odd_Bloke> smoser: I'm scoping out Python 3 changes; would we be talking about supporting Python 2 _and_ 3, or shifting to just Python 3? <Odd_Bloke> smoser: If both, is just 2.7 acceptable? <JayF> I definately use cloud-init on boxes with only py26 :( <JayF> (CentOS 6) <smoser> Odd_Bloke, 2 and 3 <smoser> Odd_Bloke, https://code.launchpad.net/~harlowja/cloud-init/py2-3/+merge/225240 <smoser> that is harlowja's start. <Odd_Bloke> smoser: Thanks for the pointer. <harlowja> smoser ok back! <harmw_> https://cloud-images.ubuntu.com/utopic/current/utopic-server-cloudimg-armhf-disk1.img <harmw_> smoser: can I just add that to glance? <harmw_> you happen to know? <harlowja> harmw u can try my tool @ https://github.com/stackforge/anvil/blob/master/tools/img-uploader.py <harlowja> if it still works, ha <harlowja> https://github.com/stackforge/anvil/blob/master/anvil/components/helpers/glance.py is the code that it uses to extract image, upload it... <harlowja> should still work i think (although it may expect an image archive with a kernel and ram disk as well) <harmw> harlowja: could you decribe what it tries to do? :) looks like extracting initrd+kernel and adding that to glance, right? <harlowja> ya <harmw> (im unsure on how to exactly get ARM images in glance) <harlowja> pretty much :-P <harlowja> let me look at, forgot what it does, haha * harlowja wrote it to long ago <harlowja> from what i remember, it calls into https://github.com/stackforge/anvil/blob/master/anvil/components/helpers/glance.py#L439 <harmw> ok, so, why :p since kernel+ramdisk are often just supplied :p <harlowja> which then calls into to extract, register, upload @ https://github.com/stackforge/anvil/blob/master/anvil/components/helpers/glance.py#L391 <harlowja> harmw mainly u have to associate the ramdisks and crap with the raw image file, although if u just have a single image, i think u can just upload that directly <harmw> glance image-create --name 'Ubuntu Utopic ARM' --disk-format raw --container-format bare --property architecture=armv7l --file utopic-server-cloudimg-armhf-disk1.img <harlowja> ya, something like that should work also <harmw> I'm hopeing it will :p <harmw> libvirtError: internal error: no supported architecture for os type 'hvm' <harmw> hm <harlowja> hmmm, ya, not sure about that one <harlowja> https://ask.openstack.org/en/question/7519/instance-error-caused-by-libvirterror-internal-error-no-supported-architecture-for-os-type-hvm/?answer=7520#post-id-7520 <harlowja> maybe 'libvirt_type=qemu' <harlowja> in nova.conf <harmw> nah, I apparently didn't load kvm - trying to that now <harmw> *krnel module <harlowja> k <harmw> ah, yes, I needed the -lpae kernel for that <harmw> hmk, well, I can boot a vm from that image - but it doesn't show anything in the console.log <harmw> or am I using the wrong hardware thingy here <harlowja> unsure :-P #cloud-init 2014-11-18 <harlowja> smoser when u get some time, can u lookover the following 2 <harlowja> https://code.launchpad.net/~harlowja/cloud-init/setup-virtualenv-installable <harlowja> sorry, 3 , ha <harlowja> https://code.launchpad.net/~harlowja/cloud-init/fix-digital-ocean-test-py26 <harlowja> https://code.launchpad.net/~daniel-thewatkins/cloud-init/ssh-equals <broskos> Hello - anybody on with a moment to help me troubleshoot? <broskos> I am trying to pass a chef config via os33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abheat33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abloudconfig. After boot, my instance logs a cloud init error : <broskos> 2014-11-18 12:05:15,134 - util.py[WARNING]: Running chef (<module 'cloudinit.config.cc_chef' from '/usr/lib/python2.7/site-packages/cloudinit/config/cc_chef.pyc'>) failed <broskos> I get what seems like a properly formatted cloud config file <broskos> cat /var/lib/cloud/instance/cloud-config.txt #cloud-config # from 1 files # part-001 --- chef: environment: LOCAL run_list: - recipe[rms-app-go_server] server_url: https://dpyc111f98ef.lab.rmsonecloud.net:4040 validation_key: '-----BEGIN RSA PRIVATE KEY----- <broskos> In fact, If I copy the 'chef' block out of cloud-config.txt and paste it into /etc/cloud/cloud.cfg and remove the instances cache <broskos> I can run cloud-init -d modules and my chef config builds fine in /etc/chef <broskos> I can't figure out how to troubleshoot further <broskos> disregard - whatever the issue, it seems resolved in 0.7.7 <harmw> god.. does greendns.py realy -not- support ipv6? <harmw> ERROR oslo.messaging._drivers.impl_rabbit [-] AMQP server on bla:5672 is unreachable: [Errno -9] Address family for hostname not supported. Trying again in 13 seconds. <harmw> seriously, Rabbit.. #cloud-init 2014-11-19 <anotheral> question: what do I need to do to get cloud-init to reload the ubuntu user's authorized keys from AWS metadata, when i'm creating a new AMI? <harlowja> anotheral typically clearing out the cloud-init data folder should do it <harlowja> http://cloudinit.readthedocs.org/en/latest/topics/dir_layout.html <harlowja> if u are making a new AMI i would also do other cleanup to <harlowja> cleaning out any other settings (your own ssh keys that were installed...) <anotheral> yeah it's very weird - i'm starting with an official ubuntu 12.04 daily AMI <anotheral> instantiate it, clear out /var/lib/cloud and ~ubuntu/.ssh/authorized_keys <anotheral> and make a new AMI. the authorized_keys file remains empty when I instantiate the new AMI <harlowja> hmmm <harlowja> seems odd, that shouldn't happen <harlowja> do u have the cloud-init log files from when u make a new instance from your new AMI? <anotheral> lemme check those <broskos> I'm using cloud-init with a chef block to install and run chef. How can I notify cfn or heat when the chef run has completed? Is there a way to do this with cloud-init? <harlowja> broskos i thought the heat folks had some callback mechanism? perhaps asking in #heat channel ? <broskos> harlowja: thanks, I'll try. <broskos> I see their waithandles and such, and cfn-signal which is pretty straight forward. Just working on sorting out how to tell when the chef run is finished at the moment <harlowja> ya, i know one way cloud-init can do it, but i thought the heat folks used a different strategy <harlowja> aka, http://cloudinit.readthedocs.org/en/latest/topics/examples.html#call-a-url-when-finished is one way, but i didn't think this was the way <harlowja> that more of signals when cloud-init is done, which could be used to also say 'chef' is done <broskos> saw that thanks. <broskos> can't seem to get it to send the right bits back to heat <harlowja> let me know if u find out, i've always wondered how to and never had enough time to investigate <broskos> still poking - I'll come up with somehting... I just mostly wanted to make sure I wasn't overlooking something more obvious <harlowja> broskos u might be interested in https://code.launchpad.net/~harlowja/cloud-init/better-chef-module/+merge/238040 which yahoo is using (until that merges) <broskos> k <harlowja> adds more configurability... <broskos> heh - had to hack in a small portion of that myself. <broskos> current version doesn't run chef-client except on a gem install <broskos> I'll keep an eye on that branch, it's much better than what Ive got going <harlowja> :) <broskos> harlowja: ok - from within heat you create your wait_condition and your wait_handle <broskos> like this guy does here: <broskos> https://developer.rackspace.com/blog/openstack-orchestration-in-depth-part-2-single-instance-deployments/ <broskos> very basic, name them what you will <harlowja> k, then heat just polls until that stuff is done? <broskos> the wait_handle when you reference it will return a url that you can post to <broskos> so now you can use phone_home <harlowja> ah <broskos> phone_home: url: Ref: "GoServerWaitHandle" post: [ instance_id ] <broskos> you can also daisy chain config blocks and user data together via mulipart mime <broskos> and they will process sequentially, <broskos> so chef config first, then one that does a notfiy back using heat stuff... <harlowja> right <broskos> but that is more complicated than what I needed, since I only wanted the chef config to notify <harlowja> not many people know about that mime multipart stuff, the heat folks do, ha <broskos> I found it confusing, mostly because there are 3 different template formats and various posts will have used a format slightly different that what you are using causing a lot of time interpreting and converting <harlowja> ya :-/ <broskos> in the end I got the multipart mime to work, but then backed it out and when back to phone_home #cloud-init 2014-11-20 <lindenle> I/j #packer <anotheral> i'd asked on tuesday about an AMI that won't populate ssh keys <anotheral> ~ubuntu has an empty authorized_keys file in the AMI, and it's not getting filled out when I launch an instance <anotheral> here's the log entry: <anotheral> Nov 20 21:15:41 ip-10-10-4-181 [CLOUDINIT] __init__.py[DEBUG]: handling ssh-import-id with freq=None and args=[] <anotheral> nothing after it <anotheral> full log is here: http://paste.ubuntu.com/9132258/ <anotheral> and ec2metadata has the correct keys <sauce> which AMI? 12.04? <sauce> the cloud-init on the 12.04 is so old, mostly nothing works, so i basically use runcmd echo a ton. "echo mydata >> /home/ubuntu/.ssh/authorized_keys" for example <anotheral> sauce: yeah, 12.04 <anotheral> ok, that helps a bunch <sauce> thats your problem <anotheral> at least i'm not crazy <sauce> whatever ssh module you're using won't work <anotheral> guess i get to tell my users we're upgrading :-D <sauce> well before you do that, check out how 14.04 AMIs behave. i have no experience with 14.04 yet <anotheral> what I'm trying to do is just extend the base AMI with some company-specific stuff <sauce> oh. so take 12.04 and upgrade the cloud-init <sauce> then do your stuff <sauce> then AMI it #cloud-init 2014-11-21 * mhayden tips his hat to JayF * gholms waves at mhayden <JayF> Hey smoser, mhayden is another long-time racker <harlowja> mhayden hey, for https://code.launchpad.net/~rackerhacker/cloud-init/add-ipv6-static-address-support a coworker at y! is also working on this, https://bugs.launchpad.net/cloud-init/+bug/1391695 ; she should have that up for review today, hopefully we can look at both and merge them or something <JayF> he's going to be tossing a patch your way for IPv6 static support <harlowja> JayF i saw that :-P <mhayden> harlowja: good timing ;) <harlowja> ;) <mhayden> harlowja: should i add a mention of my branch in that ticket? <harlowja> sure, although both of u guys i think started a solution at the same time, ha <harlowja> concidence :-P <mhayden> i'm curious to see the other solution as this is my first time working with cloud-init ;) <mhayden> well, working with the code itself i mean <harlowja> agreed <harlowja> she'll be in shortly i think <harlowja> mhayden another intersting question is whether ipv6 works for the other distros also <harlowja> that network conversion (from ubuntu -> internal format) is also used in freebsd for example <mhayden> my changes only add in some new dict keys <mhayden> so it shouldn't affect them unless they blindly write whatever is in the dict <mhayden> i didn't check around for that <harlowja> ya i don't think they do, but my guess is they are also not ipv6 compat <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/distros/sles.py#L56 <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/distros/arch.py#L63 <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/distros/freebsd.py#L273 <mhayden> ah so yeah, the sles one would just write IPv4 config only <harlowja> ya <mhayden> would it make sense in the future to put all the network config into json and avoid parsing the debian-style network config? <JayF> mhayden: That's what I'm doing :) <harlowja> +1 <harlowja> ;) <mhayden> then i owe you tacos, JayF <JayF> mhayden: https://github.com/racker/cloud-init/pull/1 is the downstream patch we use for OnMetal now (I think it's enabled on the whole cloud at this point, perhaps?) <JayF> mhayden: we put some info in vendor_data that's based on a spec upstream for openstack to put in json network data, and read that today <harlowja> https://review.openstack.org/#/c/85673/16/specs/kilo/approved/metadata-service-network-info.rst right? <JayF> mhayden: when openstack's upstream one comes, we'll migrate off our vendored one and go to the upstream one <JayF> aye, capn <JayF> although tbh I'm not working on it actively right now <harlowja> whose 'Claxton Correya' i don't think thats an alias for u <harlowja> lol <harlowja> maybe it is though <mhayden> it's his pen name <harlowja> cools <mhayden> i'm kidding ;) <harlowja> me too <harlowja> :) <smoser> hey all. i'm sorry for not being present. <smoser> been traveling / working last three weeks and not much else. <harlowja> spandhe mhayden welcome, both fixing ipv6 <harlowja> :-P <mhayden> yay <spandhe> haha <harlowja> mhayden spandhe i think uploaded https://code.launchpad.net/~shraddha-pandhe/cloud-init/cloud-init-ipv6-support if u want to check thato ut <mhayden> taking a look <mhayden> looks reasonable except i might toss in a "IPV6_AUTOCONF=no" into cloudinit/distros/rhel.py <mhayden> just for completeness <mhayden> since there's going to be a static assignment <mhayden> but i like that spandhe remembered NETWORKING_IPV6 in /etc/sysconfig/network -- i forgot <spandhe> mhayden: I thought BOOTPROTO=static will take care of it.. <spandhe> Ill look up more about autoconf <JayF> spandhe: not always ime <JayF> spandhe: IPV6_AUTOCONF=no basically maps directly to the sysctl iirc <spandhe> mhayden: I also put the routing info and ifconfig support.. <mhayden> good stuff, spandhe <mhayden> i'm not sure about the issues caused by leaving out IPV6_AUTOCONF... but i haven't seen any providers that due IPv6 via SLAAC yet <mhayden> it would hopefully protect the VM against router advertisement attacks though <spandhe> thanks mhayden ! will add unittests soon too.. also, for now, makes sense to keep autoconf = no.. nova currently doesnt provide any information about it.. so safe it keep it no.. <mhayden> cool <mhayden> i still haven't wrapped my head around writing tests in python :) <spandhe> mhayden: cool :) need to addcsupport for IPV6ADDR_SECONDARIES later.. <mhayden> that will be fun <mhayden> do you have a use case for it? i don't <mhayden> we assign a single IPv6 address per instance for now <mhayden> anything other than that would be a floating/shared IP <spandhe> right.. not for now.. but when we have multiple later with global scope, etc, we can add it.. <mhayden> makes sense <mhayden> harlowja: i'm a launchpad dunce -- how do i kick out my branch proposal? <harlowja> i believe there is a delete branch that i think u can access on https://code.launchpad.net/~rackerhacker/cloud-init/add-ipv6-static-address-support if thats what u want to do <JayF> mhayden: ++ absolutely hardening against RA attacks is perfect <mhayden> harlowja: yeah, i'll yield to spandhe's work there <mhayden> done <mhayden> JayF: yay <harlowja> kk <harlowja> smoser alright got http://cloudinit.readthedocs.org/en/latest/topics/modules.html to generate more goodness <harlowja> example @ http://cloudinit.readthedocs.org/en/latest/topics/modules.html#debug <harlowja> woot <harlowja> looks good this time <harlowja> http://cloudinit.readthedocs.org/en/latest/topics/modules.html#ubuntu-init-switch also #cloud-init 2014-11-24 <spandhe> mhayden: hey! I made a few changes to the IPv6 commit.. saw some issues earlier with a scenario with multiple NICs.. fixed that and updated the unittests.. http://bazaar.launchpad.net/~shraddha-pandhe/cloud-init/cloud-init-ipv6-support/revision/1036 and http://bazaar.launchpad.net/~shraddha-pandhe/cloud-init/cloud-init-ipv6-support/revision/1037 <harlowja> more easily reviewable @ <harlowja> https://code.launchpad.net/~shraddha-pandhe/cloud-init/cloud-init-ipv6-support/+merge/242547 * mhayden ganders <harlowja> damn ubuntu format! <harlowja> lol <harlowja> someday we'll get off that * mhayden crosses fingers for github one day ;) <mhayden> spandhe: i can't see anything problematic in those commits <mhayden> thanks for working on those <spandhe> mhayden: in rev 1035, on lines 87 and 88, there was an issue <spandhe> dev_name was used outside of the loop.. and that loop iterates over the interfaces.. <spandhe> actually, not outside of the loop, but it wasnât initialized.. <mhayden> ah okay #cloud-init 2014-11-25 <harlowja> spandhe mhayden alright, merged that branch <harlowja> my guess is the other non-rhel, non-ubuntu distros that also use that parsed format will need updating if they want to have ipv6 support <spandhe> harlowja: awesome! thanks! <harlowja> np <harlowja> btw spandhe if u feel interseted, and u want to add comments to some code let me know <harlowja> i started adding http://cloudinit.readthedocs.org/en/latest/topics/modules.html#debug and <harlowja> http://cloudinit.readthedocs.org/en/latest/topics/modules.html#chef <harlowja> but need to fill out the others <harlowja> if people want to help, feel free ;) <harlowja> format @ http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/config/cc_chef.py#L21 <harlowja> which then will turn into that web format when parsed <harlowja> i know people loving writing comments/docs <harlowja> lol <spandhe> harlowja: haha <harlowja> i
{'channel': 'cloud-init', 'month': 11}