#cloud-init 2014-01-02 <harlowja> arg, harmw so close, except need to modify the ufs image and rhel doesn't come with ufs module that seems to work, lol <SnoFox> No topic ...? I didn't realize that was possible. <harlowja> seems like even ubuntu creates a RO ufs module, arg <harmw> harlowja: what do you try to do? <harlowja> need to put some files in /tmp (jsonpatch...), but instance under libvirt doesn't have networking yet, and durn RH and ubuntu ship read-only ufs modules <harmw> why doesn't it have networking? <harlowja> ya, not sure, haven't investigated that much yet :-P <harmw> i can imagine rc.conf lacking some networking settings, though running dhclient should just give you an adress <harlowja> kk, let me try <harlowja> ah, it works <harlowja> sweet <harlowja> arg, of course no wget, lol <harmw> fetch :) <harmw> and perhaps even curl, not sure though <harlowja> hmmm <harlowja> this should let me download jsonpatch and stuff <harlowja> pita, lol <harmw> this beeing fetch? <harlowja> ah, i got wget installed :-P <harmw> in usr/local/sbin perhaps? <harlowja> let me check <harlowja> crazy bsd, lol <harlowja> ;) <harlowja> oh, i guess i can put all the needed files that aren't installed on a fat disk, and then avoid all this stuff, hmmm <harmw> or you just wget/fetch the jsonpatch and cloudinit tarballs and unzip those ;) <harlowja> ya ya :) <harlowja> gonna get this to work :-P <harmw> harlowja: http://paste.openstack.org/show/59693/ I'm seeing this on accasion, while creating/destroying instances <harlowja> ah, good ole neutron <harlowja> :-/ <harmw> any ideas where/how to debug this? since it doesn't always happen <harlowja> hmmm <harlowja> i bet thats your keystone timing out <harmw> lol, i thought the same thing <harlowja> how are u setting up keystone? <harmw> mysql+memcached <harlowja> multi-process? <harlowja> 1 process? <harmw> no, just 1 <harmw> keystone-all <harlowja> ya, i bet thats causing it <harmw> hm, is multi-process something new in havana? <harlowja> nah, its been an ongoing fight for that <harmw> because this only started since after the upgrade from grizzly <harlowja> https://alexanderlisa@example.com/msg03715.html <harmw> keystone token-get is slow aswell, sometimes it returns in <1s while it can also take an average of 10s <harlowja> hmmm <harmw> (I should mention its a rather old Atom cpu though) <harlowja> do u have a script running that cleans up the token database? <harmw> keystone is running 100%cpu most of the time <harmw> my token table is empty <harlowja> k <harmw> since memcached takes care of that <harlowja> right <harlowja> 100%cpu not good <harlowja> http://docs.openstack.org/developer/keystone/apache-httpd.html <harlowja> u can try that <harlowja> so much stuff hits keystone that its a good idea to scale it > 1 <harmw> true <harlowja> its the first thing to fall over really <harmw> though why didn't this happen with grizzly? <harlowja> unsure <harmw> mind you, I'm running a tiny tiny cloud with just 2 nodes <harlowja> :-/ <harlowja> and its running at 100% <harmw> indeed <harlowja> that seems off :-/ <harlowja> bb, food <harlowja> keystone logs useful? <harmw> :) <harmw> ahno <harmw> i had verbose+debug on, nothing interesting <harmw> i think this Atom just sucks bigtime at doing all the PKI stuff, causing it to max at 100 <harmw> bedtime now harlowja, let me know how your fbsd stuff ends <harlowja> ends, probably never ends, haha :-P #cloud-init 2014-01-03 <harmw> harlowja_away: :) <harlowja> let me see how much farther i can get today harmw , nearly there i think <mbarr> I'm trying to find the code for the puppet module in cloud-init. part of it is just what variables are available for interpolation into the puppet.conf file.. can someone point me to it? <mbarr> I've looked in the bzr repo, and don't see anything, but it clearly works... <harlowja> mbarr http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/config/cc_puppet.py <mbarr> and there's nothing about modules in the current docs site. <harlowja> mainly line 51 and on <mbarr> Hmm... i wouldn't have expected it inside config. <harlowja> :) <mbarr> that's why i didn't find it :) <harlowja> back in the day i tried to name that differently <harlowja> *name the folder differently <harlowja> i failed, haha <mbarr> ahh, there is only the %f & %i. got it. <mbarr> What's interesting is that I'm trying to change the hostname of the system early enough to be picked up by puppet, and it gets cranky.. <mbarr> Thus, the code is helpful. <harlowja> hmmm <mbarr> i suspect it's starting the puppet instance before the runcmd actually changes the hostname. <harlowja> are u using the sethostname module? <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/config/cc_set_hostname.py <mbarr> That was what i was *just* looking at. <mbarr> It's not documented at present in the main docs. <mbarr> so thus.. the code. it is helpful :) <harlowja> ah <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/config/cloud.cfg#L40 <harlowja> runcmd happens after pupper <mbarr> I could switch it to bootcmd, and it'd be OK, it looks like. <harlowja> ya, i suspect so <mbarr> I was figuring i would just read code, and figure it out :) <harlowja> although set_hostname module runs after bootcmd <mbarr> or i could just use the set_hostname and it'd be fine too. <harlowja> so it might get overwritten <mbarr> preserve_hostname would prevent that, or i could just do the puppet command by hand. <mbarr> however, it's annoying to have to edit the defaults file. <mbarr> So i was looking to see how you dealt with it. <harlowja> hmmm, i haven't use the puppet stuff personally :) <mbarr> That's oK. <mbarr> it's just using the autostart(). <mbarr> I could not bother w/ the init script and just run it, and mostly, it'd be fine. <harlowja> :) <mbarr> i just really wanted to see how this thing worked, and seeing the order was actually key :) <harlowja> def <mbarr> I'm attempting to give more info to things like logs, so i need my hostnames to have some info as to role, but also still be unique, and auto scaleable... <mbarr> oh what fun autoscaling is <mbarr> I end up w/ hostnames like webserver-prod-us-east-1c-i-2828384.ec2....... <mbarr> thank you, I'm glad to see that the project was included in RHEL 6.4. That'll make this a fairly standard option now. <harlowja> def <mbarr> Thanks again! wonderful job :) <harlowja> np <harlowja> ha <harmw> harlowja: any luck? <harlowja> ah, haven't had time yet <harmw> ok <harmw> harlowja: you work at yahoo, right? <harlowja> correct <harmw> you're behind the ads.yahoo.com malware? :p <harlowja> lol <harlowja> nope <harmw> :) what is it you do, software developer? <harlowja> yuppers, openstack software developer guy <harmw> cool <harmw> developer or also responsible for the yahoo cloud running smooth and gentle? <harlowja> a little of all the things :-P <harlowja> more developer, less smooth running person <harlowja> i try to not get involved there <harmw> haha <harmw> and yahoo pays you to 'just work on openstack'? <harlowja> pretty much <harmw> thats pretty cool <harmw> just you or a team of several? <harlowja> openstack to big for 1 person ;) <harlowja> so more than 1 <harlowja> less than 50 <harlowja> :-P <harmw> thats quite a few :) <harmw> and something similar to keep the yahoo cloud running? <harmw> and please forgive me for beeing curious :) <harlowja> np <harlowja> well its almost the same team, we have to be pretty well connected with the people running it <harmw> obviously <harmw> how large is your deployment anyway? <harlowja> ah <harlowja> now u getting into the intereting questions :-P <harmw> :> <harlowja> ya, that one i can't easily say <harlowja> but in the thousands <harlowja> thats the estimate i can say <harmw> instances? <harmw> (vm's) <harlowja> lets say both to that <harlowja> lol <harmw> ok <harmw> compute nodes? <harmw> and what kind of storage do you use? <harmw> something iscsi-ish? or a ceph cluster? <harlowja> hmmmm <harlowja> lol <harlowja> ya, not sure if i can answer that one :-P <harlowja> *not yet at least* <harmw> lol <harmw> because you don't know or because it's a secret :p <harlowja> well lets say its a WIP <harlowja> lol <harlowja> on something, lol <harmw> lol, do tell :> <harlowja> ha <harlowja> someday when i can :-P <harmw> haha, though by then it's probably on yahoo.com/cloud/solution/bla <harlowja> link not work :-P <harmw> :> <harmw> btw, is the yahoo cloud private or public? <harmw> since there's no easy reference on yahoo.com <harlowja> private <harlowja> http://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/yahoo-case-study :-P <harlowja> with me <harlowja> lol <harmw> lol nice <harmw> you're the bald guy from the still? :p <harlowja> lol <harlowja> 2 bald guys are in that video <harlowja> but yes <harmw> oh haha <harlowja> :) <harlowja> bb food <harmw> :) nice talk <harlowja> ha <harlowja> thx <harlowja> alright, harmw finally getting back to freebsd #cloud-init 2014-01-04 <harlowja> harmw nearly there, seanb is gonna work on the rc.d script adjustments <harlowja> make them work there, and then it should just work <harlowja> ha <harmw> harlowja_away: cool <harmw> i haven't taken the time to work out initscripts, and if seanb is working on that ill keep my hands off :) #cloud-init 2014-01-06 <smoser> kwadronaut, wrt your question on ssh keys <smoser> you can just configure that portion off <smoser> just add something like this to a '*.cfg' in /etc/cloud/cloud.cfg.d/ <smoser> http://paste.ubuntu.com/6703527/ <smoser> and take out the '-ssh' <smoser> do that on "first boot" and subsequent ones wont run it. <smoser> you wont/wouldn't get ssh keys pulled from metadata service into your user's .ssh/authorized_keys, but thath probably isn't a huge deal for you in that case. <smoser> you could also use harmw's suggestion of <smoser> http://cloudinit.readthedocs.org/en/latest/topics/examples.html#configure-instances-ssh-keys <smoser> and just write that stanza explicitly from the files in /etc/ssh after first boot. <smoser> (so each boot would just explicitly re-write them) <harlowja> harmw ya, i think he is, will bug him today to see how far he got <harmw> ok harlowja #cloud-init 2014-01-07 <pquerna> smoser: your proposal for requiring a matching label is good; I'll get the CLA done in a bit. <smoser> pquerna, thanks. <harlowja> harmw just fyi, sean got sucked into some y! mail thing yesetday, will be getting around to sysvinit scripts soon <kwadronaut> thanks smoser, i will have to look at it later. <lotia> greetings all. <lotia> using trying to figure out how to prevent filesystems and mount points from being configured on ubuntu 12.04 instances running on ec2. would i just put required config files in /etc/cloud.cfg.d/ <harlowja> lotia that would work #cloud-init 2014-01-08 <smoser> lotia, yes, you can do that or give user-data to do it. <smoser> ie, something that isn't well understood / known is that cloud-config provided by userdata == cloud-init configuration files in /etc/cloud/cloud.cfg.d/ <harmw> harlowja: I read yahoo switching to https on e-mail, probably related :) <harlowja> harmw i think so :-P <alevy> HI all, my ssh key does not seam to get imported from openstack when cloud-init runs. How would I debug this? <harlowja> alevy which datasource are u using with openstack? <harlowja> config drive? <harlowja> other? <harlowja> what version of cloud-init <alevy> harlowja: im not sure what data source, how do I check? 0.7.3 <harmw> cloudinit will tell you which sources it tried <harlowja> do u know how the openstack u are using is setup? <harlowja> that will affect which datasource cloud-init should try <harlowja> but as harmw said, the console log of openstack should also tell u what was being tried <harmw> you didn't forget to pass --key mykeyname on booting the instance alevy :) <harlowja> and if not /var/log/cloud-init.log usually has more <alevy> harmw: started it from the console <alevy> harlowja: it is a nebula one openstack cloud <alevy> one image is working the other isn't... <harmw> nova boot --flavor bla [..] --key-name thisismykey <harmw> ah <harlowja> alevy hmmm, then it could vary, do u know what the nebular people recommend for images? <smoser> alevy, you can check to see if your key is there in 'ec2metadata' <harlowja> is that image known to work (that they are providing) <harmw> which image works, which one doesn't? <alevy> the one someone downloaded but I am trying to build my own (for certain rrsons) <smoser> i think nebula use ubuntu cloud images (even pull them in by default) <alevy> both centos 6.4 with the same cloud-init package installed and same config <harlowja> alevy build your own, hmmm <alevy> Can i run it interactively to see what is happening, I dont understand what is in the logs... <harlowja> alevy is it possible for u to pastebin the logs somewhere (filter out anything u don't want to show?) <alevy> smoser: how do I check that <alevy> harlowj: sure <smoser> alevy, in ubuntu you'd have a package 'ec2metadata' <smoser> just run it and it will crawl the metadata <smoser> from inside the system (assuming you got in, but you clearly might not bee able to) <alevy> smoser: bash: ec2metadata: command not found <alevy> smoser: centos <smoser> ah. well then <harlowja> logs at /var/log/cloud-init.log should be useful here <harlowja> *if any <smoser> $ curl -q http://936-429-9875/latest/meta-data/public-keys; echo <smoser> 0=brickies <alevy> curl -q http://936-429-9875/latest/meta-data/public-keys; <alevy> 0=alevy <alevy> looks ok there... <alevy> does cloud-init care about selinux? <harlowja> define 'care'? <smoser> it should handle it. <smoser> i have to run <smoser> later. <alevy> harlowja: i noticed one image has it enabled and the other doesn't, just looking for differences... <harlowja> kk, can u also check the diff between the cloud.cfg files @ /etc/cloud/cloud.cfg <harlowja> a diff there might be part of the issue <alevy> harlowja: nothing commented out matters right? <harlowja> right <alevy> ok they are identical then <harlowja> hmmm, k, thats pretty odd <alevy> harlowja: is there a way to run cloud-init and see if it is puking or something? <harlowja> ya, u can run cloud-init just via $ cloud-init <alevy> do indents matter? <alevy> i.e. "-" vs. " -" <harlowja> potentially <harlowja> yaml is white space sensitive <alevy> gr <alevy> ok i see what may be the problem then <harlowja> kk <alevy> yaml is valid and nothing changed when I re-ran cloud-init <harlowja> valid yaml could still mean the yaml isn't right, if the spacing is right thats usually valid, but it might still be off <harlowja> u should be able to run $ cloud-init single 'module-name' <harlowja> and then see if one is dying <harlowja> perhaps run just the ssh one <alevy> harlowja: cloud-init single --name ssh ? <harlowja> i think so <alevy> cloud-init single --name 'ssh' --frequency once <alevy> that did something... <alevy> generated public private keypair <alevy> how do I test the fetch of keys from openstack? <harlowja> so i think u should be able to run $ cloud-init init <harlowja> and that will rerun the fetching part <alevy> does not seem to <harlowja> any output at all? <alevy> just prints out the networking stuffs <harlowja> k, its probably noticing u already fetched the data <harlowja> can u check /var/lib/cloud/ <harlowja> if u temporarily move that directory to somewhere else, it should re-run <harlowja> that directory is where cloud-init stores alot of its data <harlowja> especially under /var/lib/cloud/instance <alevy> ok moved it and now it prints the networking and generates the keys again but says Failed to generate ecdsa key <harlowja> ok, afaik rhel has issues with the ecdsa key, but the rest of the keys should be getting made, <harlowja> the question i guess is did it put your keys in place <harlowja> maybe try the cloud-init single --name ssh again <alevy> it makes the ones in /etcssh/ for sure i just checked the fingerprint <harlowja> k <alevy> is the ssh module the one that fetches the key from openstack? <alevy> http://cloudinit.readthedocs.org/en/latest/topics/modules.html <alevy> that is totally empty.. ha ha <harlowja> hmmm, ya, thought that had some data in it <harlowja> the modules are @ http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/cloudinit/config/ <alevy> https://gist.github.com/8326025 <alevy> that is the log btw, gist came back up <harlowja> ah, k <harlowja> hmmm, ya, its using 'iid-datasource-none' which confuses me <alevy> what does that mean? <harlowja> its supposed to find the ec2 one <harlowja> datasources provide where cloudinit gets info from, ec2 being one <harlowja> the none one is like a fallback <alevy> do i need to set that in cloud.cfg? <alevy> let me paste that too <alevy> https://gist.github.com/8326105 <harlowja> u can, it might help reduce the set of ones it will try <harlowja> adding the following will help reduce the options <harlowja> # Only these datasources will be attempted (in order) <harlowja> datasource_list: <harlowja> - ConfigDrive <harlowja> - Ec2 <harlowja> - None <harlowja> or something like that <harlowja> u are running the '- disable-ec2-metadata' module though <harlowja> that alters iptables, so that means u can't probably run cloud-init twice <harlowja> without unblocking that iptables filter <harlowja> probably for testing disable that module running <alevy> ok i disabled that module <alevy> and ran again <alevy> still not fetching any keys <alevy> https://gist.github.com/8326270 <alevy> https://gist.github.com/8326272 <harlowja> did u make a new instance? or the same one? <alevy> same one. should I make a new one? <harlowja> ya, if that module already ran, it turned on an iptables rule that stops the metdata from being fetched <alevy> can i just flush iptables? <harlowja> probably <alevy> seems to still be using None <alevy> ok I have to run <alevy> i guess i just need to keep looking? <harlowja> ya, make sure u are removing /varl/lib/cloud each time u try to re-run <harlowja> i'd restrict what datasources are allowed to <harlowja> to avoid all these other ones being activated <alevy> ok #cloud-init 2014-01-09 <smoser> alevy, running 'single' doesn't actually hit the datasource. <smoser> harlowja, <smoser> it just uses what it already found <smoser> you have to re run 'cloud-init init' to have it search <harlowja> ya, moving /var/lib/cloud should make that work out right <smoser> single wont re-run the search though <smoser> so it wont have pulled the data. <smoser> i dont think <smoser> this use case is one i want to solve with 'ci-tool' <harlowja> ya, k, i think alevy was running init also <alevy> harlowja: hey man if you have time I am going to roll a new instance and try to finish debugging this?your input is appreciated. <harlowja> sure, i'll have a little time today, today i have more meetings (which sux) <harlowja> smoser can probably also jump in to (or others) <alevy> ha ha <alevy> yeah understood <alevy> thx <smoser> i can help. sure. <harlowja> all smoser fault anyway alevy , lol <harlowja> :-P <harlowja> ha <alevy> thanks guys <alevy> let me get it up and see where i am at <alevy> smoser: I assume i need console=ttyS0 to make sure I can see cloud-iit output at boot? <smoser> ubuntu? <alevy> smoser: centos <smoser> i don tknwo fo sure, but quite possibly. <smoser> it depends on the sysvinit scripts <smoser> if they send output to their stdout (which i'd expect them to do) <smoser> so yeah, you probably should have that. and should log thta serial console <alevy> ok <pquerna> smoser: have you been following the systemd-networkd work? They kinda have a proposal rolling for network config files. <pquerna> smoser: ps sorry i'm bad at bzr; made it a new merge proposal :-/ <smoser> pquerna, no. alexanderlisa@example.com. network config files ? <pquerna> smoser: http://lists.freedesktop.org/archives/systemd-devel/2013-November/014077.html was the first patch, trying to find the bigger spec doc on the .network and .link file formats. <pquerna> smoser: i know the CoreOS guys are interested in getting the .link and .network files onto a ConfigDrive, rather than having to parse out the interface file. Not sure in the end its much different though. <smoser> well, i think thats wrong. <smoser> network/interfaces format is equally wrong <smoser> but openstack is stuck with it for legacy <smoser> they shouldn't go inserting some other arbitrary format in. <pquerna> i'm all for something better. <smoser> instead use something like the netcfg format or somethign. <pquerna> is anyone actually adopting netcfg though? <smoser> picking up a "standard" that is all of 2 months old isn't a good idea. #cloud-init 2014-01-10 <alevy> smoser: so i rolled one out again and i am still getting that cloud-init does not find the ec2 data source despite the fact that I can curl the API from the command line. <alevy> I keep falling back to data source none when Ec2 appears to be working by hand... <pquerna> smoser: https://docs.google.com/document/d/1ODIsSVyppkkEAun9abqazX_r8o71pVG0JHeHVCYurtI/pub has more but is apparently partly out of date. *shrug* <pquerna> i don't have a horse in it, i just write out config drives :x <alevy> smoser: python-boto was missing <alevy> that might be part of it <smoser> alevy, that'd do it. <smoser> i do plan on dropping python-boto here soon. <smoser> sorry for your lost time on that. <harlowja> smoser where is that code that i did to replace that <harlowja> i can't remember, lol <smoser> in bzr history somewhere. <harlowja> :-P <smoser> yeah, i was just going to go there. <harlowja> k <harlowja> its somewhere, lol <harlowja> harmw i'll bug sean again tommorow, i think the mail stuff is calming down (ssl seems to be on and working) <smoser> hm.. its not even there. <smoser> i thought hwe'd merged it and then dropped it. <harlowja> hmmm <harlowja> not sure, it i think was in a branch somewhere at least <harlowja> unless i deleted the branch :-/ <harlowja> smoser http://bazaar.launchpad.net/~harlowja/cloud-init/url-ssl-fixings/view/698/cloudinit/ec2_utils.py <harlowja> there u go <smoser> you want to propose that as a drop for python-boto ? <harlowja> hmmm <smoser> i'm happy to take that now i think <harlowja> sure, will see if i can do that <harlowja> http://bazaar.launchpad.net/~harlowja/cloud-init/url-ssl-fixings/view/707/cloudinit/ec2_utils.py seems even better (the final version before we said screw it, just use boto) <smoser> :) <smoser> and use requests rather than urllib i thikn <harlowja> def <harlowja> smoser will see if i can pull that off tommorow <subway> Is there a good way to set an instance hostname to something-instanceid via cloud-init? <subway> foo-%i diddn't work the way I'd hoped.. <subway> I guess I can just do it in a script instead of using a cloud-config yaml user data #cloud-init 2014-01-11 <harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/boto-ec2-replace/+merge/201269, will add some tests and all (not done) <harmw> ok harlowja_away #cloud-init 2014-01-13 <harlowja> harmw sean still dealing with mail+bsd or something <harlowja> :( #cloud-init 2014-01-14 <smoser> harlowja_away, utlemming what do you thikn about making deafult 'output' setting <smoser> ie, http://askubuntu.com/questions/345344/where-are-the-logs-for-my-user-data-script-cloud-init <smoser> for 14.04. <smoser> i think i'm going to just do that. <utlemming> smoser: +1, its really useful <smoser> i only hesitate because it is world readable <harlowja> hmmm, smoser personally i'm ok with that, but should be easily turn offable <smoser> it is easily turn-offable. <smoser> i'll go ahead and do it. <harlowja> k <bjweaver_> Do user-data scripts need to be mime encoded when placed on a configdrive ISO ? We have a user-data script out there but cloud-init does not seem to run it. <harlowja> bjweaver afaik they are written as binary files on configdrive <harlowja> so no mime-encoded needed <bjweaver> we have a bash script we need to run on boot , not sure how that would be a binary file. <harlowja> how did u upload it <harlowja> u should just be able to put it in userdata and it will run <harlowja> bjweaver can u inspect what is on the config drive and possibly pastebin the cloud-init log files? <harlowja> that should tell why it wasn't executed #cloud-init 2014-01-15 <Chocobo> Hello. What comes after generating the SSH key pair? I created a snapshot of an image and when I try to boot it seems to hang after initializing SSH. Is there a way to disable cloud-init with a kernel/grub parameter? <Chocobo> hrmmm. I even tried setting "init=/bin/bash" and "single" to no avail. Interestingly on the first boot the log shows a root prompt but the vnc console just shows a black screen with a blinking cursor. <Chocobo> I am not sure what is causing this. <bjweaver> Still trying to get cloud-init to run the user-data script on an ISO.. The script is on the ISO as openstack/latest/user_data <bjweaver> I turned up logging as harlowja suggested , added output: {all: '|tee -a /var/log/cloud-init-output.log} to cloud.cfg <bjweaver> Only thing in the log is a warning about 2012-08-10 not available and attempting to use 'latest' <bjweaver> might be magically working now <smoser> Chocobo, i can't answer you if you're not here. <smoser> bjweaver, working ? <harlowja_> harmw yt <harlowja_> smoser also, u might be interested in <harlowja_> http://paste.openstack.org/show/61294/ (config rc.d script for cloud-init) <harlowja_> *an inital attempt, feedback wanted (from sean) <harlowja_> http://paste.openstack.org/show/61295/ (cloud-final) <harlowja_> http://paste.openstack.org/show/61296/ (cloud-init) <harlowja_> http://paste.openstack.org/show/61297/ (cloud-init-local) <harlowja_> any feedback welcome <harlowja_> ^^ for freebsd <smoser> well i think that functions with a '-' in their name are not posix shell <harlowja_> k <smoser> $ dash -c 'foo-bar() {echo hi}' <smoser> dash: 1: Syntax error: Bad function name <harlowja_> ya <harlowja_> comment fwded ;) <smoser> actually, they dont even work for bash :) <smoser> $ bash -c 'foo-bar() {echo hi;}' <smoser> bash: -c: line 0: syntax error near unexpected token `{echo' <smoser> bash: -c: line 0: `foo-bar() {echo hi;}' <harmw> oh my, he's used - and _ as well :p <harlowja_> :-p <harlowja_> i told him, haha <harmw> harlowja_: i'm looking at 61296, I think lines 17 and 28 won't work this way <harmw> and command=bla differs between the different files :) <harlowja_> kk, let me bug him as this <bjweaver> smoser - I believe so.. I had to move the scripts-* up to the cloud_init_modules section. I haven't found docs on how init vs config vs final stages work. Seems our init scripts only run the init section. <smoser> bjweaver, ubuntu? <smoser> you dont want those in the modules section <smoser> as running in modules section does not guarantee network <bjweaver> This is the opensuse package port of cloud-init <smoser> i wonder are you getting networking from the config-drive ? <bjweaver> networking is coming from a DHCP server. <bjweaver> This is a project we are doing under VMware. <grepory> does documentation exist for logging configuration? cloud-init isn't generating new ssh host keys when it's being run, and i can't figure out why... the debug logs do not have anything useful in them. <grepory> As far as I can tell, logging is configured at level debug, but ... i would expect to see something about modules running at the very least, but that is not the case. <grepory> Ah because it is supposed to bail if it doesn't find a datasource. I was expecting it to use "None" as I configured it to in /etc/cloud/cloud.cfg, but to no avail. <grepory> datasource_list: ["NoCloud", "ConfigDrive", "OVF", "MAAS", "Ec2", "CloudStack", "None"] <grepory> is this insufficient? <grepory> or incorrect? <grepory> ugh n/m. figured out how config resolution works. <grepory> and that the None datasource isn't actually something you can use. <harlowja_> smoser harmw so scripts are fixed, sean i think will also package this sucker into the freebsd ports repository once it works <harlowja_> so +1 #cloud-init 2014-01-16 <smoser> horah! <smoser> bah. grepory gone. <smoser> hard to help people who leave before i come back. <smoser> None datasource should generate ssh keys i thikn <harmw> cool harlowja <harlowja> :) <harlowja> might be dropping in/out, bad wireless & meetings <harmw> did you/sean test it using the new initscripts? <harlowja> harmw going to try to today, i think he did basic testing after getting the order right <harmw> nice #cloud-init 2014-01-17 <smoser> harlowja_away, bah to pylint. new version in ubuntu alexanderlisa@example.com, spews warnings about everything. <smoser> :-( <smoser> http://paste.ubuntu.com/6768706/ <harlowja> smoser arg, stupid pylint <harlowja> logging-not-lazy <harlowja> lol <harlowja> jeez, when did pylint get so crzy <smoser> harlowja_away, https://code.launchpad.net/~utlemming/cloud-init/vendor_data/+merge/201033 your thoughts there would be appreciated also <harlowja> sure boss <harlowja> :) <smoser> some of those things its seeing are reasonable. <smoser> but some (unused-argument or unused-variable) <harlowja> ya <smoser> we named them with _ to specify that! <harlowja> nutty <harlowja> which afaik is convention <harlowja> k, scott, seems ok to me <harlowja> smoser harmw ok, tested basic freebsd (basics), seems to be starting fine and finding the distro and all <harlowja> i'll submit up the rc.d files that sean made <harlowja> https://code.launchpad.net/~harlowja/cloud-init/freebsd-rc.d/+merge/202155 <harlowja> harmw ^ <harmw> compare lines 25,26 with 33 ;) <harlowja> ya, sean and his '{' <harlowja> :-P <harlowja> will fix this for him, lol <harmw> (lines 50,51 in cloudfinal.. 2 blanc lines, instead of just 1) <harmw> and more like that as well :p <harlowja> hmmm, all fixed, lol <harmw> hm, what could/would cloudinit_override() do anyway? <harlowja> not sure, let me ask him why <harmw> ah great :) annoying stuff to bitch about, those whitelines, I know :p <harlowja> harmw thats just reflecting the same thing in the other sysvinit scripts <harmw> its the precmd, though I dont know what sourcing that specific file would accomplish <harmw> ah ok <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/sysvinit/redhat/cloud-init#L61 <harlowja> i guess just reflecting that functionality <harmw> indeed <harmw> though CLOUDINITARGS is specified in one of the files in L62 or L63 <harmw> and the freebsd script doesn't use anything that could've been specified in a sysconfig file, hence my question :) <harlowja> sure sure, understood, maybe for future use then :-P <harmw> ofc, while that could be an argument to completely drop that part for now as well :p <harlowja> either or <harlowja> harmw so i think sean will packge up any missing dependencies and get those shoved up to freebsd ports also <harmw> cool, I posted the pkg stuff already didn't I <harlowja> think so, but might just be good to make sure we have a good list <harlowja> known ones i had to install [configobj, jsonpatch, Cheetah, argparse] <harlowja> [pyserial, oauth] probably also? <harlowja> ^ those 2 are datasource usage dependent <harmw> pkg install python27 py27-yaml py27-requests py27-prettytable py27-cheetah py27-boto dmidecode e2fsprogs gpart sudo <harmw> and jsonpatch, manually <harlowja> k <harmw> though those could've brought in some of the ones you just mentioned aswell :) <harlowja> np, will make sure sean has a good list <harmw> great <smoser> harlowja, you have a thought ? <smoser> i'm looking to put vendor-data into nocloud <smoser> that would seem pretty easy <smoser> but it uses read_seeded <smoser> which looks for user-data and meta-data <smoser> both of which are "required" <smoser> but vendor-data would be optional <smoser> thats easy peasy for "file://" <smoser> but not for http:// <smoser> as we have retries built in. (and at the moment it doens't look like we have support in 'read_file_or_url' for returning None on 404) <harlowja> u should be able to check the status code of the response right? <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/url_helper.py#L86 ? <harlowja> which in the case of a file 'response' is always 200 <harlowja> how do u want it to work i guess <harlowja> is the question :-P <smoser> harlowja, http://paste.ubuntu.com/6769790/ <smoser> what do yo uthink of that ? <smoser> none_on not the best of variable names, but a list of status_codes that should return None without retry <harlowja> hmmm, what about a stop_retry_callback ? <harlowja> then u can pass that callback the last request, and it can stop the retry if it wants <harlowja> ? <harlowja> what do u think smoser ? <smoser> hm.. <smoser> so you would just pass the exception <smoser> the UrlError ? <smoser> what is check_status ? <smoser> i think i can acutally just use that. <harlowja> ya <harlowja> there u go <harlowja> seems like a good usage <smoser> k <smoser> ok. utlemming i think i'm gonna merge the vendordata stuff now. <smoser> and then i'll merge some other thigns that i think halrow had suggested <utlemming> smoser: ack <smoser> and then i'm going to work to make NoCloud take vendordata <smoser> utlemming, i think that 'mergedvendoruser' is vestigial <smoser> right? <harlowja> like my third baby arm <harlowja> errr <harlowja> haha <smoser> yeah, i've never really understood why you have 3 arms <smoser> wierd <harlowja> lol <harlowja> not my fault at summits that the 3rd baby arm hits u in face, lol <harlowja> *mind of its own and all <smoser> harlowja, you there? <smoser> your added tests/unittests/test_ec2_util.py <smoser> has 2 test_metadata_fetch_key <smoser> jeeze harlowja . <smoser> now i have to fiddle wit hthis biuld-depends thingy httpretty <harlowja> lol <harlowja> smoser well its a nice http testing library <harlowja> it should hopefully already exist <smoser> yeah. but lots of fallout <smoser> bddeb now busted <smoser> (due to version) <harlowja> hmmm <smoser> and the version you depend on is > what we have in trusty <smoser> (but you work on trusty) <smoser> so i'm dropping that to 0.7.0 <harlowja> k <harlowja> i think thats fine <harlowja> i can alter it if we really need <harlowja> and drop it <smoser> ithink th eeasies tthign right now is to drop it as a 'Requires' <smoser> but i guess i'd like a BuildRequires or somthin and put that in <smoser> but we have to plumb that into the ./packages <harlowja> ya, typically test-requires right? <harlowja> and thats only used for testing <smoser> is it. <harlowja> so then it doesn't need to be in buildrequires either <smoser> ? <harlowja> ya, from what i've seen at least <smoser> well in ubunt packaing i'm running the tests <harlowja> kk <smoser> so a file 'test-requires' ? <harlowja> sureee <harlowja> at least thats how openstack projects do it, maybe there is a different way <smoser> yeah. thats fine. <smoser> i'm gonna commit something really quick here to just drop tha tfor now <smoser> could you try to do a test-requires ? <smoser> err.. i'll handle that <smoser> ok. well, just pushed. './tools/bddeb -us -uc' works again <harlowja> i can <harlowja> shall i? <smoser> i added test-requires <harlowja> kk <smoser> but tidoesnt get used anywhere really. <harlowja> can probably add it to the makefile when make test is ran <smoser> alright. i have to run. <smoser> have a nice weekend all. <smoser> thanks for work. <harlowja> byeeeeeeeee! <smoser> i'll do more cloud-init work monday i hope <harlowja> *waves 3rd arm <smoser> and vendordata support for openstack (through the ec2metadata service) <harlowja> ya, i gotta work more on my openstackdatasource <smoser> and then when we get that Openstack datasource (that harlowja) was going to add... <smoser> :) <smoser> night night <smoser> later. <harlowja> lata <kwadronaut> morning <kwadronaut> cloud-init query --name instance_id gives me NotImplementedError: Action 'query' is not currently implemented <kwadronaut> which makes me a sad panda. using the package from debian backports, 0.7.2 Is this expected, anything i can do t ofix it? <harlowja> hmmmm, i still think its not fully implemented (unless i forget) <harlowja> https://code.launchpad.net/~harlowja/cloud-init/query-back-duo <harlowja> kwadronaut ^ <harlowja> 'Integrate a slightly cleaner query tool, bring it back to life!' <harlowja> lol <kwadronaut> heh <kwadronaut> it's i think good to have, especially for beginners trying to debug. <harlowja> agreed <harlowja> most of the data though is at /var/lib/cloud/ though <harlowja> http://cloudinit.readthedocs.org/en/latest/topics/dir_layout.html <harlowja> but not so easy as just using that tool <kwadronaut> yep #cloud-init 2014-01-18 <smoser> harlowja, $ sh -c ': ${cloudinit_config}:="/etc/cloud/cloud.cfg"}; echo $cloudinit_config' <smoser> at https://code.launchpad.net/~harlowja/cloud-init/freebsd-rc.d/+merge/202155 <smoser> prety sure that is wrong. <smoser> kwadronaut, yeah, there is no query. -( <smoser> would like to get there. <smoser> harlowja, above, that syntax is not going to do what you would think (and i think it is supposed to do) <smoser> i think there should not be the first closing paren <smoser> ie, should be: <smoser> : ${cloudinit_config:="/etc/...cfg"} <smoser> but even that i think might be wrong <smoser> ok. to be clear, this looks wrong: <smoser> ': ${cloudinit_config}:="/etc/cloud/cloud.cfg"}; echo $cloudinit_config <smoser> and i think it should be: <smoser> : ${cloudinit_config:="/etc/cloud/cloud.cfg"}; echo $cloudinit_config <smoser> bah. drop the '; echo...' at the end that was just my testing. <smoser> i think yo uprobably cna make out what i intended to say. <harlowja> lol <harlowja> k <harlowja> smoser so sean hopefully will upload freebsd ports missing requirements soon, i'll bug him about it next week, depending on where he is <harlowja> and then up goes cloud-init <harlowja> *in the same repos <harlowja> and then we can get freebsd working even more <harlowja> and so on... #cloud-init 2014-01-19 <Lexis> Hello #cloud-init 2014-01-20 <smoser> harlowja_away, around ? <natorious> trying to get cloud-init running on Gentoo <natorious> there appears to be a package in portage but installing it doesn't provide any init scripts <natorious> would copying the rhel init scripts be all thats needed? Anything else I might run into? <pquerna> smoser: cla thing is recorded. #cloud-init 2014-01-21 <smoser> pquerna, thanks. <smoser> natorious, well its not much use without init :) <smoser> i'd guess that the sysvinit scripts should be reasonably re-usable, but i don tknow how gentoo does boot order dependency resolutoin stuff. <iliyas> How do we define multiple sections of a YUM repo file in YAML form ? <harlowja> smoser just got baack <harlowja> ya, as for gentoo, not quite sure about the boot order, the scripts though should work fine <smoser> iliyas, mulitple sections ? <smoser> harlowja, i think i say never mind now. <smoser> oh... i dropped your 'sudo pip install' <harlowja> its ok <smoser> i would like targets of 'make pip-depends' <smoser> or somethign like that <harlowja> or venvs? <harlowja> there is always that <iliyas> Yes, like [section-1].... [section-2]... in a single .repo file. <smoser> yeah, i want pip-depends to work. in venvs <smoser> or to be able to say 'make apt-depends' <smoser> and apt-build-depends <harlowja> smoser hmmmm <harlowja> what would apt-build-depends do, make the packages? <harlowja> btw, another question smoser making this DatasourceOpenStack over the weekend, do we want to keep dataSourceConfigDrive? <harlowja> since DatasourceOpenStack basically absorbs pretty much all of its functionality <harlowja> + more <smoser> harlowja, not make the packages <smoser> just install them <smoser> .PHONY same <smoser> harlowja, i think we want datasourceconfigdrive <smoser> yes, but it does share a *lot* of code with datasource openstack <smoser> but at the moment the only way we configure thingson or off at is the sources/DataSourceXXX level <smoser> that make sense ? <smoser> and i was planning on trying to get to add vendordata ocnsumption to the datasourceconfigdrive and to the nocloud <harlowja> k <harlowja> i'm splitting shared functionality smoser off into helpers module anyway <harlowja> but not much left in ConfigDrive after that split, lol <smoser> yeah, and thats fine. <harlowja> k <smoser> but i think that its reasonable to say "i only want ocnfig drive" <harlowja> sure <smoser> or "i only want openstack metadata service". <harlowja> or u want both <smoser> yeah. <harlowja> k, thats similar to what i am doing #cloud-init 2014-01-22 <abk> would maintainers be interested to have varied linux/bsd distro compatible logic to configure system settings like network/pasword in an adapter fashion <smoser> abk, we can configure network to some extent, and you can add users and set their password that works in linux. i'm not sure if it would work in bsd. <abk> smoser, I'll be working on a binary reaching via cloud-init into instances taking care of all these base configuration on VMs which get pushed by Hypervisor during build <abk> smoser, I thought if cloud-init can use it up... will instead write as a component of it instead <smoser> abk, we can make cloud-init consume such data for sure. <abk> smoser, distros supporting (RHEL,Fedora,CentOS,Debian,Ubuntu,Gentoo,Arch,OpenSuse,FreeBSD,Scientific) and all major version of these <smoser> i'm not sure what you meant by "binary reaching via cloud-init". <abk> smoser, I'm not very well-versed in cloud-init yet... but what I notice is I can get my service doing these tasks via any bootstrap script using cloud-init's userdata <abk> smoser, but if it can be a part of cloud-init (as in if you folks and community is interested)... I'll instead put it somewhere where it's much easily usable by anyone desiring such feature <smoser> ok. yeah, right. i would be interested in that, yeah. <smoser> passing network settings in is currently kind of tricky/broken <smoser> it should work except for the case of 'eth0' (or any other "auto" configured devices with information already in the instance) <smoser> ie, ubuntu cloud images ship with 'auto eth0' (for dhcp). <smoser> and changing that is not really functional <smoser> because we don't bring *down* interfaces when we configure networking passed in. <smoser> :w <shardy> Hey guys, noticed the docs have been bumped to 0.7.5, but the latest tagged release is still 0.7.4 <shardy> is a new release imminent? <shardy> smoser: That's a question directed at you I guess :) <smoser> not imminent, but development is open. <smoser> the rtd is keyed off of Changelog i guess ? <harlowja> smoser i think the rtd is keyed off the version.py in cloudinit <harlowja> not changelog afaik <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/rtd/conf.py#L41 <harlowja> smoser yt, ok with merging https://code.launchpad.net/~harm-o/cloud-init/freebsd ? <harlowja> sean here is gonna start pushing the people in the release team for freebsd to start making openstack images i think <harlowja> using that freebsd stuff (and any future changes) <smoser> i hadn't really alexanderlisa@example.com. <smoser> i recently changed cc_growpart <smoser> so i would have thoguht the merge thing would not like line 70 in that diff <smoser> https://code.launchpad.net/~harm-o/cloud-init/freebsd/+merge/198130 <smoser> and i think that VERSION (line 701) is going to piss off someone who was here before with some other distro. <smoser> but ... ok. merge i guess. <smoser> oh wait. <smoser> one thing <harlowja> harmw yt :-P <harlowja> ^^ <smoser> never mind. harmo signed agreement. cool. <utlemming> smoser, harlowja: has anyone confirmed if the disk paritioning code works with this mp? <harlowja> i havent <harlowja> but my guess is its not 100% complete <harlowja> thats why seanwbruno just arrived <harlowja> hahaha * seanwbruno stops trolling from afar <utlemming> harlowja: that is my guess <harlowja> seanwbruno to fix it all! <seanwbruno> pfft <harlowja> haha <harlowja> seanwbruno i think is gonna try to bug the freebsd people to make better partitioned images, then hook this in <harlowja> but he can explain i guess <seanwbruno> dealing with $work horse shit at the moment, but tomorrow I'll get with the fbsd re team to put something out that looks like our franken-images at the office. <harlowja> lol <seanwbruno> I may way to scrape the fbsd cloudinit stuff into a port for others if that's not in the works already. <harlowja> i don't know anyone else doing it <seanwbruno> hrm, I wonder if a fbsd ports has a hook into launchpad yet. <seanwbruno> let me parse some make files <harlowja> parse those makes files, lol <harlowja> *make files <harlowja> harmw yt <seanwbruno> well, my cursory "grep -ri launcpad" doesn't seem to indicate any kind of helper stuff. <seanwbruno> is there a shortcut URL that would engrabinate a tgz/tar/whatever of a LP repo? <harlowja> smoser ? <harlowja> ^ <seanwbruno> not vital, just being lazy <harlowja> probably is some way <smoser> i dont think there is. <seanwbruno> well, I can just checkout the tree and tgz it myself. <seanwbruno> like I said, just being lazy <smoser> you're saying wget http://some/url/lp:cloud-init > trunk.tar.gz <smoser> right ? <seanwbruno> smoser: aye <harlowja> seanwbruno one think i beleive will need adjustment (especially for y! use-case) will be the config-drive usage, which i believe that branch doesn't fixup <harlowja> *especially around network settings being written <harlowja> basically the config-drive in openstack contains a network settings file, which cloud-init then translates into whatever version it understands for the current operating system <harlowja> looking at that review <harlowja> 407 + def _write_network(self, settings): <harlowja> 408 + return <harlowja> :) * harlowja not really sure how freebsd handles network configuration files and stuff <seanwbruno> if you want static configs, we'll have to construct an entry for rc.conf or rc.conf.local (preferred) and splat it in there <seanwbruno> I suspect, that most configs will want to be splatted in there. <harlowja> k, thats probably not that bad <harmw> i didn't implement setting up networking in rc.conf just yet iirc <harlowja> ah, k, harmw were u planning on, maybe that can be seanwbruno 'get wet' commit, lol <seanwbruno> lol <harlowja> *ok that probably wasn't a very good selection of words <harlowja> whatever <harmw> ;) <seanwbruno> I smell a "print" command coming on. <harmw> I wasn't planning on coding that tonight though <harlowja> lol <harlowja> tommorow night then? <harlowja> :-p <harmw> friday's more like it :p openstack shows networking stuff per ec2 api, right? <harlowja> hmmm <harmw> besides config-drive (which I dont use) <harlowja> not exactly <harmw> stuff like bla/local-ipv4 <harlowja> ah, i think for the ec2 usage, people mainly rely on dhcp <harlowja> for config-drive its pretty different <harmw> indeed it is, pretty much straightforward in that case <harmw> perhaps i can parse the dhcp lease file and configure that to be static <harmw> to cope with scenarios where networking is not done through a metadata api <harlowja> http://paste.ubuntu.com/6798907/ is whats in the config-drive <harlowja> basically a ubuntu network file :-P <harmw> yea, I noticed the rRH scripts rebuilding that blob to something RH understands :p <harlowja> :) <harlowja> ya, josh's custom parser <harlowja> haha <seanwbruno> I have some hackery somewhere to parse that things somewhere. <harlowja> ya, the _write_network(self, settings): should get the parsed object <harlowja> not the raw string (i think) <seanwbruno> ooo <seanwbruno> I even did it in /bin/sh <seanwbruno> wow ... such code <harlowja> ah, maybe not, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/distros/rhel_util.py <harlowja> thats josh parser <seanwbruno> oh <seanwbruno> so <seanwbruno> that's another thing I wanted to ask <seanwbruno> why on earth isn't all the network data in the meta.js file? <seanwbruno> I was confused why I had to parse meta.js for a couple of config elements but all the network data had to come from some janky redhat file. <harlowja> lol <harlowja> legacy <seanwbruno> gross <harlowja> thats really all <harlowja> *janky ubuntu file ;) <harlowja> lol <seanwbruno> I was so happy (for a moment) when I could just do json parsing from single command line invocations of python and then got super confused by the then parsing of compeltely seperate network config file <harlowja> :) <harlowja> openstack started off being much more ubuntu specific, so that piece has stuck <seanwbruno> something like this was what I was going to put in a rc script somewhere. <seanwbruno> http://bpaste.net/show/171009/ <harlowja> soemday https://fedorahosted.org/netcf/ might be used <seanwbruno> I'd have just voted to cram it into the meta.js object and be done with it. <seanwbruno> but <seanwbruno> whatever <seanwbruno> also, hooray for outputting text with python only to then turn around and pass it to grep/awk * seanwbruno is a silly, silly man. <smoser> they picked that /etc/network/interfaces file <smoser> that was a bad decision <smoser> but unfortunately, bad decisions mean legacy dependencies. <smoser> and they cant change *that* file. <smoser> they could provide it in a more sane format elsewhere though. <smoser> (and probably should) <harlowja> ya <smoser> http://paste.ubuntu.com/6798955/ <harlowja> so thats why u see weird RHEL converter <smoser> that make sense ^ <smoser> i'm gonna commit it. python parsing of requirements.txt and ChangeLog <smoser> i tihnk we can assume core python <harlowja> seems ok to me <harlowja> seanwbruno steal the RH converter, it already translates ubuntu format to agnostic format <harlowja> and then just write agnostic format out to freebsd format <harlowja> it probab ly doesn't need tobe in a file called rhel_util <smoser> read-version is 4 times slower after my python rewrite :) <smoser> but oh well <harlowja> goooo python! <smoser> python3 is only twice as slow as python2 in this case. <harlowja> :( <harlowja> smoser another thing i was thinking about <harlowja> to make cloud-init work in both 2 and 3 <harlowja> already done quite a bit of that in taskflow using the six module <harlowja> probably not so bad to do it in cloud-init <harlowja> then it will be 2 and 3 compat <smoser> i'd like that. <smoser> we dropped boto that is good <smoser> the python-oauth is another woone that has to be replaced <harlowja> kk <harlowja> should be simple to do six stuff <harlowja> now that i know how to use it pretty well <harlowja> then u won't be blocking ubuntu move to py3 <harlowja> seanwbruno u didn't go through the CLA stuff yet right? <harlowja> *ubuntu CLA <harlowja> *not openstack CLA <seanwbruno> harlowja: nah <harlowja> k <harlowja> seanwbruno smoser i think https://code.launchpad.net/~harlowja/cloud-init/net-distro-util/+merge/202743 should make it more obvious that u can use the same function <harlowja> harmw <seanwbruno> totally <smoser> i wont block ubuntu move to py3. but dont think we'll get that in in trusty. <smoser> that'd have to happen "really soon now". <smoser> i was kind of planning on it as 0.8.0 <harmw> harlowja: please extend the comments a little to describe what this agnostic format looks like <harmw> since now one needs to go over the source, and I'm way to lazy to do that :p <harmw> otherwise, looks like a nice change <harmw> and usable, ofc <harlowja> harmw sure <harlowja> will do <harlowja> if i can remember, haha <harmw> :) <harlowja> smoser i don't think six stuff will take that long really <harlowja> its pretty straightforward <smoser> i think its a pita. <smoser> i liked my ignorant magic handling of unicode <smoser> or string. <smoser> and open() and write(string_or_unicode) just working <harlowja> lol <harlowja> ya <harlowja> its dumb, i agree <harlowja> https://code.launchpad.net/~harlowja/cloud-init/net-distro-util/+merge/202743 harmw <harlowja> comments added <harmw> nice <harmw> (though I'm missing a newline on L85 :p) <harlowja> hmmm <harlowja> k <harmw> anyway, I think it's not that hard to have fbsd use this function to get the networking done - provided the image was booting with a config drive <harlowja> agreed, it shouldn't be <harmw> and if it wasn't booted using config-drive, it should figure out what to configure per what it got through dhcp <harlowja> yup <harmw> that'll have to wait 'till the weekend though :) <harlowja> seanwbruno can do it to :-P <harlowja> get his feet wet <harlowja> either way <harmw> ah, well in that case I'll o it right now :p <harlowja> lol <harmw> tomorrow, probably <harlowja> all good #cloud-init 2014-01-23 <harlowja>
{'channel': 'cloud-init', 'month': 1}