#cloud-init 2013-09-05 <kwadronaut> so, I read the docs: https://cloudinit.readthedocs.org/en/latest/topics/modules.html and think i still have some questions ;-) <smoser> kwadronaut, you can ask htem here. <kwadronaut> smoser: cheers. First question is: how can I contribute to that specific page? <smoser> its managed from code. <smoser> so you can write doc and make bzr merge request. <kwadronaut> oh bzr. i forgot that. <kwadronaut> which module would (re)generate ssh server keys? <kwadronaut> (I'm using the Debian packages) <smoser> 'ssh' does that. <smoser> cloudinit/config/cc_ssh.py <kwadronaut> thanks <kwadronaut> hmmm i am missing the right way to have it only run once (use case: take a snapshot, boot that, don't get a new ssh-key) <smoser> kwadronaut, it should only run once. <smoser> by default <kwadronaut> in that case, i'll compare what i changed half a year ago with the defaults. <smoser> so the way that is handled is that the default is 'PER_INSTANCE'. <smoser> the module can define *its* defualt, by defining 'frequency' in it. (cc_ssh does not do that). the values expected are one of <smoser> PER_INSTANCE = "once-per-instance" <smoser> PER_ALWAYS = "always" <smoser> PER_ONCE = "once" <smoser> and cloud-config can define a overriding value. <smoser> see example of 'cloud_config_modules' in doc/examples/cloud-config.txt <kwadronaut> ah, but instances get a new instance-id here if you snapshot and fire up the snapshot <kwadronaut> thanks, i'm reading <kwadronaut> that document both has [ cloud-init-per, once, mymkfs, mkfs, /dev/vdb ] and [ apt-update-upgrade, always ] <kwadronaut> i guess 1 way would be less confusing <smoser> kwadronaut, well, cloud-init-per is just a generic command. <smoser> that you can can put into /usr/local/bin/ scripts or whatever <smoser> and it will run the command provided according to that frequency. <smoser> it may not actually be necessary in that case any more. <smoser> but at one point bootcmd's didn't work for frequency <smoser> oh. yeah. you do need it there. <smoser> because 'bootcmd' module does run 'per_always' <smoser> but if you only want a command to run once or per-isntance, then that command has to control itself. <smoser> kwadronaut, ^ did that make sense ? <kwadronaut> i guess so, i was getting some food and will have a closer look today or tomorrow. #cloud-init 2013-09-06 <PedroAlvarez> Hi! How can I know if cloud-init is installed on my OS? <PedroAlvarez> btw,. smoser, I hacked the setup script to support an older grep version. <PedroAlvarez> The grep commands on the script are using perl regular expressions <kwadronaut> PedroAlvarez: which OS are you using? <PedroAlvarez> kwadronaut: custom core linux distro <kwadronaut> i don't know that one, i'd say use your package manager and see if it's installed, have a look in /etc/cloud* /var/log/cloud* do a find for CloudConfig on your filesystem. <PedroAlvarez> kwadronaut: Sorry, you miss understood me, Is not a distro. <PedroAlvarez> It wasn't installed. Now I have it working in my OS, time to solve dependencies! :) thanks! <smoser> PedroAlvarez, so 'tools/read-dependencies' wsa giving you grief? if you have a suitable replacement for that grep, that is fine. <PedroAlvarez> smoser: the grep commands in 'tools/read-dependencies' works fine without the '-P' option. <PedroAlvarez> smoser: but I had to change the 'tools/read-version' grep's regular expression, using '[0-9][0-9]*' instead '\d+'. <smoser> PedroAlvarez, does this work for you: http://paste.ubuntu.com/6070291/ <PedroAlvarez> smoser: I did this and it worked: http://paste.ubuntu.com/6070304/ <smoser> http://paste.ubuntu.com/6070306/ <smoser> can you try that diff, pedro ? <smoser> PedroAlvarez, <smoser> or i could do them both with sed. does your sed have '-n' ? <smoser> VERSION=$(sed -n '/^[0-9]\+[.][0-9]\+[.][0-9]\+:/ { s/://; p; :a;n; ba}' "$CHNG_LOG") <PedroAlvarez> sorry smoser: I cannot send you diff now. <PedroAlvarez> I used this and worked fine <PedroAlvarez> VERSION=$(grep "[0-9][0-9]*.[0-9][0-9]*.[0-9][0-9]*:" "$CHNG_LOG" | cut -f1 -d ":" | head -n 1) <smoser> well, if youcould tell me if this works, i'd appreciate it. <smoser> http://paste.ubuntu.com/6070331/ <smoser> i suspect it does <smoser> sed -n is nothing new. <PedroAlvarez> -n Suppress automatic printing of pattern space <PedroAlvarez> supported here ;) <smoser> right. <smoser> it was supported on aix in 1999, so i figure its pretty safe. <PedroAlvarez> smoser: I will tell you later if it work, thanks for helping <PedroAlvarez> s/work/works/ <smoser> http://paste.ubuntu.com/6071174/ <smoser> harlowja, ^ is a "shell parser" <smoser> http://paste.ubuntu.com/6071190/ <smoser> and there it runs with 'bash -r' <smoser> https://gist.github.com/smoser/6466708 <harlowja> holy crap <harlowja> your shell foo is better than mine, ha #cloud-init 2013-09-09 <harlowja> smoser hopefully the commit should be ok now :-p <harlowja> can do schema stuff later <harlowja> u think schema stuff way to go? <smoser> harlowja, i like the 'validate' <smoser> and i'm fine with 'json-schema' <harlowja> cool <smoser> a module wouldn't have to use json-schema <smoser> but probaly would <smoser> (and could run the schema and then further test some stuff in its validate) <smoser> you tihnk it seems sane ? i hope? <smoser> and did you look at the opennebula stuff ? <smoser> i'm really leaning towards just pulling their stuff in. <harlowja> haven't check opennebula stuff recently <harlowja> :-/ <harlowja> ya, no need for module to use json-schema, just provide its own validate() method <harlowja> that the cloud-init stages can call before running <smoser> why's it called 'json schema' ? <smoser> really its just 'dict, list, string, int' schema <smoser> right? <harlowja> ya <harlowja> :-p <harlowja> got me, i guess the RFC is for json , but not really limited to <harlowja> http://json-schema.org/ <harlowja> sorry, not RFC, ' IETF published draft ' <harlowja> *whatever that is, ha <smoser> harlowja, <smoser> http://paste.ubuntu.com/6085177/ <smoser> adding that <smoser> harlowja, is there a better way to read /sys ? <smoser> should i use read_file_or_url there ? <smoser> for mocking / wrapping / test purposes <smoser> harlowja, please think, respond, and i'll update and merge your code and then we'll have "random seed" support on azure too <smoser> wee! <harlowja> haha <harlowja> weee <harlowja> smoser why not just load_file ? <harlowja> u can still mock load_file ot <harlowja> *out <smoser> duh. load_file. yeah. #cloud-init 2013-09-10 <harlowja> :) <smoser> merged. thanks. <harlowja> np <harlowja> smoser so when u gonna help out with taskflow?? <PedroAlvarez> Hello <PedroAlvarez> There is any log of what happening with the user-data commands? <smoser> PedroAlvarez, /var/log/cloud-init.log has cloud-init log <smoser> by default output of anything done goes to /dev/console <smoser> which on openstack can be read with 'nova console' <smoser> if you want to chagne that default, you can set output via cloud-config 'output' <smoser> see example / description at http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt <smoser> i use <smoser> output: {all: '| tee -a /var/log/cloud-init-output.log'} <smoser> by default. #cloud-init 2013-09-11 <PedroAlvarez> smoser: Doing this change: http://paste.ubuntu.com/6070331/ I have this error: <PedroAlvarez> RuntimeError: Failed running ['tools/read-version'] [rc=1] (, sed: can't find label for jump to 'a}') <smoser> PedroAlvarez, that really should be "standard sed". <smoser> workson gnu sed and busybox sed. <PedroAlvarez> smoser: This is the change I did to get it running: http://paste.ubuntu.com/6093190/ <smoser> try adding either a ';' or a ' ' after 'ba' <smoser> or both <PedroAlvarez> smoser: but I have it already running. <smoser> but i'm asking you to od something that doesn't require 3 forks and actually checks for failure correctly. <smoser> (all yours does is check that 'head -n 1' succeeded. <PedroAlvarez> smoser: ok :) <smoser> and will silently echo nothing and not fail) <PedroAlvarez> smoser: it works http://paste.ubuntu.com/6093408/ <smoser> PedroAlvarez, ok. i'll commit. <smoser> thanks. <PedroAlvarez> smoser: are you going to merge it with the trunk branch? <PedroAlvarez> smoser: tvm <smoser> pushed revno 868. <PedroAlvarez> :) #cloud-init 2013-09-16 <technolo-g> hi all :) <technolo-g> im having an issue in which cloud-init on rhel is not utilizing the config_drive provided by openstack. im currently running 0.6.3-0.12. Is it just too old of a version to pick up the configdrive (which is properly provided as disk by label config-2) <smoser> technolo-g, config-drive-v2 support came in 0.7.0 <smoser> ubuntu carries backport to 12.04's 0.6.3 <technolo-g> has anyone built >0.7.x on rhel6 do you know? <smoser> technolo-g, i dont know. harlowja ^ <harlowja> ya, its been built <harlowja> in active use at y! <harlowja> rhel version 6.2, 6.3 <technolo-g> great, thanks guys. I'll see if i can track it down. <technolo-g> once it is installed, it should automatically be looking for that configdrive correct? or do i need to specify a datasource? <smoser> probably should, yesh. <technolo-g> excellente, thanks again :) <technolo-g> ok, sorry for the lazy questions, but im having a hard time finding how to explicitly set a datasource on an installed cloud-init. would it be possible to point me in the right direction? The datasources doc does not (that i can see) demonstrate how to set the datasource <smoser> technolo-g, well its just a cloud.cfg setting. <smoser> datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, Ec2, CloudStack, None ] <smoser> unless your config (or packaged config) overwrote it, it should be there. <technolo-g> ok cool, i do have that. ill give it a shot <technolo-g> alrighty, so running 0.7.1 (the only srpm i could find that would build on rhel6), when specifying the ConfigDrive datasource it just doesn't seem to find anything. i am still able to mount the configdrive itself and browse the contents. am i hitting this fix maybe? <technolo-g> - allow config-drive-data to come from a CD device by more correctly <technolo-g> filtering out partitions. (LP: #1100545) <technolo-g> that was it :) now to do it cleanly #cloud-init 2013-09-17 <pedroalvarez_> smoser: do you know which library needs "sources/DataSourceSmartOS.py" when it does `import serial`? <pedroalvarez_> Because this one doesn't look ok to me: http://pyserial.sourceforge.net/pyserial.html <smoser> http://pyserial.sourceforge.net/ is it. <smoser> why "doesn't look ok" <pedroalvarez_> Just because I don't understand why it needs a library to use the serial port.. <smoser> utlemming, ^ . i dont know for sure. <smoser> i'm open to sipmle file io. on it <pedroalvarez_> smoser: It also uses "boto", is this one? https://pypi.python.org/pypi/boto <pedroalvarez_> to access Amazon web services? <smoser> it uses boto to crawl the metadata service on amazon. <smoser> basically turn their web service data into a dict. <pedroalvarez_> smoser: thanks for the info :) <utlemming> smoser: the answer is yes, because otherwise reading the serial is a real pita <harlowja> utlemming probably u would have to rewrite a mini-version of pyserial to do it right, which does seem like duplicated work <harlowja> *thats sort of the whole point of libraries* <harlowja> pedroalvarez_ if u don't need certain datasources u can remove dependencies <harlowja> aka if u don't care about enabling DataSourceSmartOS.py remove the pyserial dependency <smoser> i dont really know about reading form serial devices. <smoser> i'm perfectly fine to replace it with something else that works. <smoser> pySerial is ubuntu-main (a requirement in the end). that does'nt mean other things can't be there, and we get them into ubuntu main. but it sure is nice if the thing is already there. #cloud-init 2013-09-18 <smoser> harlowja, thoughts: <smoser> https://code.launchpad.net/~vlastimil-holer/cloud-init/net-reconfigure/+merge/186352 <pedroalvarez_> Hi, I have configured cloud-init in a linux image, but when I boot the image, the systemd services crash. When I start them manually it works. What could it be? <smoser> pedroalvarez_, i'm not sure. i've never used systemd. <smoser> what is 'crash' ? <smoser> logs ? <pedroalvarez_> smoser: http://paste.ubuntu.com/6124789/ <harlowja> ya, maybe logs, i haven't used systemd either myself (yet) <smoser> well it sure thinks it failed to create the user <pedroalvarez_> If I do: `systemctl start cloud-init` it works. <pedroalvarez_> And if I reboot the image, sometimes it starts. <pedroalvarez_> I want cloud-init to execute commands at boot time, through the "customization-script" of OpenStack <harlowja> ya, thats fine <harlowja> pretty normal use-case <pedroalvarez_> And, correct me if I am wrong, the services running are essential <harlowja> likely :) <harlowja> *likely u are right <harlowja> pedroalvarez_ is this systemd via fedora <harlowja> or systemd via some other distro? <pedroalvarez_> customized core linux <pedroalvarez_> baserock <pedroalvarez_> I have located the systemd files on /etc/systemd/system <pedroalvarez_> And I made a symlink in /lib/systemd/system/multi.user.bla.wants <pedroalvarez_> Also in /lib/systemd/system/ <harlowja> hmmm, eck, defintly outside of my area of expertise :( <pedroalvarez_> smoser: Does the install script try to copy them? <pedroalvarez_> harlowja: no worries :) tvm <harlowja> pedroalvarez_ can u just use the init.d versions instead of the sytemd ones? <harlowja> that might work better, idk <pedroalvarez_> harlowja: I'll try init.d version then :) thanks <harlowja> those work on RHEL6 and such <harlowja> and i know the upstart ones work <harlowja> since smoser uses them <harlowja> the systemd ones i think work with fedora, but i don't know if smoser or me have to much experience with them <smoser> yeah, i have no idea on systemd. <smoser> harlowja, did you see above? <harlowja> smoser that review looks ok, an interesting approach with the 'pretend' <smoser> why is it 'pretend' ? <smoser> what was that for. i didn't understand. <harlowja> def _write_network(self, settings, pretend=False) <smoser> right. what is that doing ? <smoser> other than for testing. why would i want that. <harlowja> ah, k, got your question <harlowja> digging deeper, incase i missed why its being used, ha <harlowja> i think its for <harlowja> dev_names = self._write_network(settings, pretend=True) <harlowja> self._bring_down_interfaces(dev_names) <harlowja> which is like a way to figure out the device names to bring down <harlowja> although i would think its a little convoluted :-P <harlowja> just have a 'list_interfaces' function and bring those down, ha <harlowja> so from my understanding, whats happening <harlowja> is that its pretending to write out the network interfaces, the result of this gives u the device names, and then the code is ifdown those <harlowja> and then it writes out in non-pretend mode <smoser> so the reason for this being is https://bugs.launchpad.net/cloud-init/+bug/1225922 <smoser> in short, if the system is booting, eth0 might have already been 'ifup'ed. and then we write a new /etc/network/interfaces file. <harlowja> gotcha <smoser> (ifup'ed successfully or non-successfully) <smoser> we need to bring it down and then back up. <smoser> and ideally we dont run 'ifdown -a' <harlowja> so the pretend thing is really just a way to list the interfaces by using the same code that writes out the interfaces (which returns a list of device names) <smoser> and 'ifup -a' <smoser> (although that i a hacky solution) <smoser> ah. <harlowja> pretend make sense now? <harlowja> thats my interpreation <smoser> but where does he call with 'pretend'? <smoser> ah. i see. <harlowja> 19 + if bring_up: <harlowja> 20 + dev_names = self._write_network(settings, pretend=True) <harlowja> 21 + self._bring_down_interfaces(dev_names) <harlowja> it is a little convoluted i guess, haha <harlowja> a function like 'list_interfaces(settings)' <harlowja> that returns the device names <harlowja> probably would be clearer to understand <smoser> yeah. <smoser> parse the existing <smoser> parse the new <harlowja> ya, since all that write_network does is parse settings and write out a file <harlowja> *or files <harlowja> want me to comment on that review <harlowja> or u got it under control boss <pedroalvarez_> Ok, after see that cloud-init service tries to create an "ubuntu" user, and then another service tries to use "apt", I think it thinks I'm running ubuntu <harlowja> :) <harlowja> haha <pedroalvarez_> hahahahaha <harlowja> ya, so u need to edit the cloud.cfg for that <pedroalvarez_> harlowja: good news then? <harlowja> yup <harlowja> # System and/or distro specific settings <harlowja> # (not accessible to handlers/transforms) <harlowja> system_info: <harlowja> # This will affect which distro class gets used <harlowja> distro: rhel <harlowja> something like that <harlowja> you are probably using the default ('ubuntu') <harlowja> and the other part is what modules u have left active by default in cloud.cfg <harlowja> some of them are more ubuntu speicfic <harlowja> *aka ones starting with 'apt' and such <harlowja> all smoser fault, ha <pedroalvarez_> The other problem of initialization is just because cloud-init needs ssh services running, and cloudinit doesn't wait I think. <smoser> harlowja, i'd appreciately comement. <smoser> pedroalvarez_, the user is configurable. <pedroalvarez_> smoser: that's cool <pedroalvarez_> I think I found all my problems on this file! :) <harlowja> :) <pedroalvarez_> I'm going home happy today <pedroalvarez_> I owe you a couple of beers <harlowja> ha <harlowja> np <harlowja> cloud.cfg is the magic file <smoser> cloud.cfg is the magic. <harlowja> all the magic #cloud-init 2013-09-19 <pedroalvarez> Hi :) <pedroalvarez> I'm trying to do a configuration of the magic cloud.cfg. I see a tag to set the users which are going to use some modules. What about if I just have a root user? Is enough to set "disable_root" to false? <smoser> pedroalvarez, i dont know. root user is untested. <pedroalvarez> smoser: Morning :) <smoser> it could work. <pedroalvarez> I'm missing something, cloud-init executes the cloud.cfg file, but is not receiving the "user-data" script. <pedroalvarez> from OpenStack <pedroalvarez> Hmmm... I see there are another projects: "cloud-utils" and "cloud-initramfs-tools" <pedroalvarez> Does openstack need them to communicate stuff to the image from the "user-config" box? <smoser> pedroalvarez, no. <smoser> can you pastebin /var/log/cloud-init.log ? <smoser> it should log there. <pedroalvarez> smoser: it's empty <smoser> that is odd. <smoser> i'm really sorry, pedroalvarez . i'm being pulled on oher things right now. i can't help. you probably want to just try runnign 'cloud-init --local init' <smoser> and then cloud-init init <smoser> you shoudl be able to run those manually <smoser> and look at debug output or debug manually <smoser> and get somewhere. <smoser> i'm sorry i cna't help more. <pedroalvarez> ok smoser no worries <pedroalvarez> you have been a great help this time <pedroalvarez> :) #cloud-init 2013-09-23 <smoser> harlowja, are you awake yet? <harlowja> sup <harlowja> smoser poke <smoser> hey <smoser> harlowja, i was gonna ask you to look at gholms mp for selinux <harlowja> whats that <harlowja> u took golhoms ring <harlowja> why did u do that <harlowja> *gollum <harlowja> ah, a review :-P #cloud-init 2013-09-25 <daveops> I'm not sure how well cloud-init is supposed to support RHEL-based OSes, but I'm having issues with it not setting the hostname permanently. <daveops> Related (old) bug: https://bugzilla.redhat.com/show_bug.cgi?id=750979 <daveops> tl;dr the correct hostname gets set on the first boot, but is unset on subsequent boots because RHEL uses /etc/sysconfig/network instead of /etc/hostname <daveops> CentOS 6.4 guest, cloud-init-0.6.3-0.12.bzr532.el6.noarch <smoser> daveops, 0.6.3 == old <smoser> should be fixed in newer <daveops> smoser: thanks... i figured it was pretty antiquated. i'll update my stuff. <harlowja> if u get stuck daveops let me know, y! runs 6.3, 6.2, 6.4 internally using cloud-init <harlowja> and even 5.8 (yes i know) <daveops> harlowja: thanks. i got it working on my version by doing some hackery in my cloud.cfg. i'm just removing /etc/hostname with a bootcmd command. it's not pretty, but we need to pull our packages from EPEL and that's the latest version they have atm. <harlowja> ah <harlowja> ya, in about 10 years RH will have the newer version <harlowja> lol <harlowja> +- <daveops> haha... right? <harlowja> ya, we fight with that stuff daily <daveops> harlowja: how are you guys addressing the issue? <harlowja> old depenedencies <harlowja> we build it :-P <harlowja> its not so hard, its hopefully pretty much 'make rpm' <harlowja> we have a few patches for cloud-init modules that do some y! stuff that also gets sucked in <daveops> oh.. nice. i'll test it out and maybe we'll just end up doing that <harlowja> but thats about it <harlowja> ya, it shouldn't be to bad <daveops> appreciate the advice <harlowja> np <harlowja> if its not just 'make rpm' let me know daveops and then something has to be fixed <harlowja> of course u might want to have a patch for cloud.cfg if u build it yourself <harlowja> to remove various things <harlowja> *debian/ubuntu things <harlowja> those nasty things smoser put in there, ha <daveops> for sure... i'll just steal the patches the fedora guys are using <smoser> everything should "do the right thing", no? <harlowja> i think so <harlowja> but just incase, ha <harlowja> i typically just reconfigure cloud.cfg to what y! wants, and remove all the other stuff <harlowja> but people don't have to do that if they don't want <harlowja> its not that many changes really <smoser> https://code.launchpad.net/~gholms/cloud-init/rsyslog-programname/+merge/186906 <smoser> i'm not sure what i htink about that one <smoser> it just seem like possibly something could go wrong ... <harlowja> hmmm, whats the issue, i'm not really a syslog expert :-/ <smoser> yeah. thats why i dont want to just take it. <smoser> i dont understand what si wrong. <harlowja> :) <harlowja> i'm with u there, maybe we can get an explanation as to whats broke <smoser> harlowja, it does work for you, right? <harlowja> not using syslog :-P <harlowja> ha <smoser> bah. <harlowja> lol <gholms> smoser: Yo <smoser> hey. <smoser> i commented in that mp. * gholms looks <gholms> Oh, the logging one. <smoser> basically "it doesnt seem to be working, but it used to, so we should change somethign ..." * gholms nods <gholms> Yeah, that is a terrible description. <smoser> :) <gholms> At that point I was terribly fatigued from working on my bug backlog all day. ;) <smoser> gholms, well, i'm expecting 0.7.3 like end of this week. <gholms> Oh! That's good to know. <gholms> I'm going to see if I can get you a better description of what it was doing, but the short version is that cloud-init logs were going to the default log file instead of cloud-init.log, and that patch was how I fixed it. <smoser> theres one change i'm expecting from utlemming, and i'd like to hvae the fix for https://bugs.launchpad.net/cloud-init/+bug/1225922 <smoser> but its tricky <gholms> That one looks fun. <smoser> gholms, yeah... i'm just weary of a config file change for something that used to work and should work. #cloud-init 2013-09-26 <gholms> smoser: My first name has two 't's in it. ;) <smoser> gholms, fixed in revno 877. Sorry about that. <gholms> smoser: No worries <harlowja> smoser do u know if there is a good email list for questions about launchpad, basic stuff like can a blueprint span 2 projects <kwadronaut> harlowja: what about https://answers.launchpad.net/launchpad or #launchpad here on freenode? <harlowja> ah <harlowja> let me try that irc channel <harlowja> thx <kwadronaut> yw <kwadronaut> there's also amy08@example.org <harlowja> cool <kwadronaut> https://xkcd.com/1254/ <harlowja> ha <harlowja> once of these will work :-P #cloud-init 2013-09-27 <pedroalvarez> Hello <pedroalvarez> I need some help configuring cloud-init. Is not for use it in a common distro as you already know <pedroalvarez> For example how can I avoid that cloudinit thinks I'am in ubuntu? Should I create a new distro configuration file? or is enough adding something to cloud.cfg? <pedroalvarez> I don't have any log as well, I only can see what is happening through `journalctl` <smoser> you will need ot have a distro. it will think yuou are ubuntu unless configured otherwise. you can tell it to think you are something else, but that might have similar fallout. <smoser> cloud.cfg says (default): <smoser> system_info: <smoser> # This will affect which distro class gets used <smoser> distro: ubuntu <pedroalvarez> I already deleted the "system_info" <smoser> so that will just use its builtin <smoser> which is probably distro: ubuntu too <pedroalvarez> I see <pedroalvarez> And, another important question is <pedroalvarez> If I want cloud init reading scripts from OpenStack, I have to configure... <pedroalvarez> a) datasource <pedroalvarez> b) datasource and something else <pedroalvarez> c) another file instead cloud.cfg <pedroalvarez> :) <smoser> the built in datasource list should contain both config-drive and ec2 <smoser> (which are the datasources openstack will provide) <smoser> you probalby have to maintain your own cloud.cfg file. or, you can overwrite things in /etc/cloud/cloud.cfg.d/MY_OVERRIDES_.cfg <pedroalvarez> smoser: Thanks, I'll continue researching around there :) #cloud-init 2013-09-28 <samppah> good evening <samppah> i'm testing cloud-init with oVirt 3.3 and centos 6.4 (cloud-init installed from epel).. it seems that oVirt is able to creat config-drive image and attach it to VM but for reason or another the VM seems to bypass it completely <samppah> any ideas what might be wrong? :) <samppah> mount LABEL=config-2 /media works fine inside VM #cloud-init 2013-09-30 <smoser> samppah, you may need a newre cloud-init than in your 6.4 centos. <smoser> i'm not sure. <samppah> smoser: ok, thanks.. i'll try to check that out :) <smoser> cloud-init config-drive came in 0.7.0. and one fix came in 0.7.2 that affected older 2.6 kernels (added by RH engineer) <samppah> ah <smoser> so you may even need 0.7.2 <samppah> i think it's something like 0.6 in epel <smoser> yeah, not good enough there. <smoser> 'make rpm' from trunk should / might give you something. harlowja uses that, but i've notn used rpms in probably 5 years. <gholms> samppah: You could build always try building fedora's source rpm on rhel. <gholms> You would have to tweak its config a bit, but it's probably doable. <smoser> gholms, have you ever used 'make rpm' ? <smoser> that "shoudl work" ? <smoser> if less than ideal in a trivially fixable way, we could fix it. <gholms> smoser: Can't say I have. <gholms> Given that it's likely to include config for the wrong init system I jusy use the same packaging code as fedora all the time. <harlowja> ya, make rpm should work, if not then its a bug i think * harlowja just got in, catching up #cloud-init 2014-09-01 <harmw> smoser`: you thre #cloud-init 2014-09-02 <nvucinic> hi guys, is there any way to find out what can i call in post in phone-home ? <harmw> what do you mean? just put in an url and it'll GET (or HEAD) that, perhaps even POST :) <harmw> yea, I think it supports POST as well - you should just look in the src though, to make sure <nvucinic> yeah, it supports post, i got the data <nvucinic> my question was this <nvucinic> example: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/891/doc/examples/cloud-config-phone-home.txt <nvucinic> what can i get except pub_keys and instance id ? <harmw> ah, you mean which items are available to post <harmw> or: keys <harmw> well, you could just look at L9 :P <harmw> post: all <harmw> just to get an idea of all available stuff, have it post everything it knows <nvucinic> let's try all :) <harmw> :) <nvucinic> not much, id, hostname and keys <harmw> well, if you need more you could fiddle in some bash script in user-data <harmw> a little adventurous, but fun :) <smoser> nvucinic, yeah, i think there isn't much else. i'm open to adding things. <nvucinic> smoser: yeah, i looked at script now :) <harmw> smoser: PING <smoser> harmw, whats up? <harmw> uhm, let me think for just a minute... <harmw> hm hm, what was it know... <harmw> :p <harmw> take a look at the fixes from last week and merge, pretty please :) <smoser> did you get the tests to pass on linux ? <harmw> harlowja fixed them <smoser> sweet <smoser> i will merge then. thanks. <harmw> awesome <harmw> and version bump to a shiny new .tar.gz , so I can submit my fbsd port as well <smoser> you really need that, eh? <harmw> if possible, yes <nvucinic> smoser: is there any way where i can check what can i get from cloud.get ? <harmw> even +1-905-866-7687 is good enough, ofcourse <nvucinic> like hostname, instance id ... <smoser> harmw, ok. we'll get something this week. <smoser> nvucinic, let me look. <harmw> nice! <nvucinic> smoser: thx :) <smoser> nvucinic, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/971/cloudinit/config/cc_phone_home.py <smoser> unfortunately, it looks like there isnt a lot. <smoser> looks like the url can have 'INSTANCE_ID' replaced in it. <smoser> and the things youi can post are listed at POST_LIST_ALL <nvucinic> smoser: yeah i replaced instance_id <nvucinic> smoser: i see that hosname is defined here all_keys['hostname'] = cloud.get_hostname() <nvucinic> so cloud.get_hostname is how you get hostname <nvucinic> cloud.get_instance_id is how you get instance id <nvucinic> is there cloud.get_xxx with list of things that i can get ? <harmw> probably not that hard to add some stuff to the cloud object <nvucinic> harmw: yeah, but what else can you get with cloud.get <harmw> its not cloud.get_BLA <harmw> its get_hostname() <harmw> or get_bla() <harmw> functions inside the cloud object (?) <harmw> so look inside for whatever functions are there to call :) <nvucinic> harmw: great, where can i get list of functions that i can use?: ) <harmw> hehe, browsing the sourcode would be a great place to start <harmw> I don't think this is listed on readthedocs <nvucinic> also if you look at http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/971/cloudinit/config/cc_phone_home.py <nvucinic> it's defined as cloud.get_hostname <harmw> def handle(name, cfg, cloud, log, args): <harmw> there's cloud <harmw> so you kinda just want to lookup what/where cc_phone_home is called from <harmw> well handle(), that is <smoser> harmw, nvucinic the cloud object is terribly not well defined. <smoser> cloudinit/cloud.py <nvucinic> yes, i can see that :) <smoser> nvucinic, so look in ther eand you can see. <smoser> and you can get cloud.datasource also <nvucinic> smoser: great, ty <smoser> which likely has more (not terribly well defined) information. <smoser> we want to get those settled down to a reasonable strucutre that we can assume is available on all clouds <nvucinic> smoser: i would like to have ip adress as argument in phone-home script <smoser> nvucinic, you can probably amy08@example.org. <smoser> is this ec2, nvucinic ? <nvucinic> smoser: no it's that god awful setup with NoCloud <smoser> nvucinic, hten its not there. sorry. <nvucinic> smoser: so custom script would be the right way? <smoser> yeah. <smoser> you can do a part-handler, or a '#!' <smoser> just run some code that reads 'ip' output (or does it in python) <nvucinic> yeah <smoser> harmw, would you mind opening a bug for "here is one unresolved issue regarding path resolving of modules (?), which is why there is one DataSource explicitly enabled in the configuration file (and working/being used)." <smoser> harmw, merged. please test it. <harmw> smoser: sure thing <harmw> and thanks :) <JayF> harlowja: thanks for the comment, I'm going to pick up work on that again today or tomorrow :) <harlowja> kk <harlowja> cool <harlowja> btw, guys something scott and i just threw together, https://etherpad.openstack.org/p/cloud-init-next <harlowja> comments welcome <harlowja> additions welcome... <harlowja> harlowja JayF ^ <harlowja> harmw i mean <harlowja> ha <harmw> harlowja: looks fine to me, though I don't have any higher level additions to share <harlowja> k <harmw> well, Windows would be nice ofcourse <harlowja> windows <harlowja> argggg <harlowja> lol <harmw> like merging some stuff from cloudbase <harlowja> ya, that one, tried that before :-/ <harlowja> i'm not so looking forward to that <harmw> hehe <harmw> smoser: just filed that bug <smoser> thanks harmw <harmw> ok, lets see if the trunk still works :) <harmw> smoser/harlowja, anyone of you using Designate btw? <harlowja> not me <harmw> oh ok <smoser> not me <smoser> harmw, bug number ? <harmw> https://bugs.launchpad.net/cloud-init/+bug/1364580 <harlowja> hmmm, odd <harlowja> can we get a log from that happening harmw ? <JayF> harlowja: is 'work with coreos on their go clone' useful input ;) <harlowja> that sounds right up there with the windows clone <harlowja> lol <JayF> harlowja: I'm 80% kidding, but I did put a note in there about making it easy to vendor your own versions of cloud-init (which go would do) <harlowja> what does mean 'vendor your own versions'? <JayF> so right now <JayF> For Rackspace OnMetal <JayF> every single one of our images <JayF> we package and deploy a custom cloud-init <harlowja> yup, same here <harlowja> *although not that custom, like 1 patch <harlowja> or 2 <JayF> This is kind of a pain in the ass because you have to 'lock' the rpm/yum version in place <JayF> which may break ON dist-upgrade or may just BREAK dist-upgrade <harlowja> ok ,don't do that lock stuff then ;) <harlowja> use the vendor provided one ;) * harlowja which is what we at y! are trying to get to (using the fedora one) <JayF> Vendor provided one doesn't support a huge stack of what we're doing <harlowja> isn't that just getting the code upstream that does that ? :-P <JayF> (which is why I'm here helping upstream our support, so we get out of this... but you and I both know if it goes upstream now I'm still packaging my own for 5+ yrs) <harlowja> hopefully more like 2 years <harlowja> haha <harlowja> ;) <JayF> It's not :( * JayF is also working on kernel version support for CentOS 6.5, which is Old Software(tm) <harlowja> overall yes though i know, avoid the fork hell at all possible <JayF> I'd say model that into upstream <harlowja> 6.5 isn't that old, thats brand new <harlowja> we have 5.8 images lol <JayF> cloud-init should assume that a lot of vendors will be packaging cloud-init and make it easier <harlowja> sure, so then what part not easy? <JayF> harlowja: Yeah, it doesn't seem bad, but even a few years with an older kernel makes huge perf differences. <JayF> Python generally doesn't make it easy :) <JayF> right now, like I said, we're just building a new RPM for a distro and 'lock'ing it there <harlowja> so more of what u are getting at is the go statically linking model? <JayF> but some supported 'omnibus' style install (like opscode uses for chef w/the ruby "omnibus" stuff) <JayF> I'm getting at I want to be able to deploy and run a 'tarball' or single file or something very isolated of cloud-init <harlowja> right, the same as statically linking <JayF> well except statically linking is an implementation of my requirement :) <harlowja> sure sure <JayF> I'm specifically not saying statically link it because I know that's mostly a nonstarter <harlowja> so then if we remove more of dependencies in http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/requirements.txt <harlowja> what about that? <JayF> think about it more this way: <JayF> as a vendor providing a cloud server <JayF> *service <JayF> we need to be able to iterate quickly on cloud-init just like we can on our cloud <JayF> packaging is somewhat of a difficulty there currently, among a bucket of other things :) <harlowja> sure <harlowja> believe me i know, lol <harlowja> but it still feels like a hammer looking for a nail <JayF> the other thing is maybe a philisophical shift: we want a mechanism to update a *booted* system <JayF> i.e. I attach some kind of 'cloud storage' volume, update the metadata service to reflect that, and my cloud init data source sees that, and mounts the volume <harlowja> ya, smoser has thoughts about that as well afaik <JayF> our use case gets more interesting because we want cloud-init (and other software) to do a lot of the tasks relegated today to a hypervisor <JayF> because hypervisors are for people who want to do things easy :P (just kidding, although it feels that way sometimes :D) <harlowja> what about helping build out something like https://github.com/cloudcadre/giftwrap <harlowja> https://github.com/cloudcadre/giftwrap#giftwrap <smoser> hm.. on a call, will look above later <harlowja> JayF afaik the above does something like what u want <harlowja> https://github.com/cloudcadre/giftwrap#how-it-works <harlowja> so thats why i wonder if its more of a problem thats outside cloud-inits scope <JayF> harlowja: IMO the problem is more on the other side <harlowja> how so? <JayF> harlowja: I build the package, install it in my default image, customer upgrades, gets a 'newer' version of cloud-init that doesn't have my patches, and cloud-init re-runs and does $unexpected_things because it doesn't support our data source <JayF> or if you do a package manager 'hold' in the distro, you restrict the customer from upgrading entire classes of packages <JayF> I don't know how to solve this problem, tbh, but I think something along the lines of chef-omnibus packages have to be the way <harlowja> hmmm, ok, sounds like u need smarter customers ;) <harlowja> problem solved! <harlowja> ha <JayF> because then I never install distro cloud-init in my images, I install cloud-init-omnibus which puts everything in /opt/cloud-init/ and depends on nothing outside that dir (except maybe libc) to run <JayF> harlowja: Our entire spiel at Rackspace is Managed [cloud|server|etc]... my job is to help write software to enable that. <JayF> harlowja: which means I'm the smarter customer :) <harlowja> :) <harlowja> i just start to wonder if there is something wrong though, like amazon afaik doesn't need to do this, yahoo has so far gotten along just fine without this kind of isolation thing, so is it really a problem that we have to resolve by isolating all of cloud-init (and its own version of python and dependencies) to say /opt/cloud-init <JayF> I'd venture to say I'm feeling this pain right now <JayF> because we're doing /new things/ <JayF> nobody before us, afaik, has run a public, software-operated, bare metal API-driven provisioning system <harlowja> sure sure <JayF> We're using network configs that are different (vlans on top of bonding) <JayF> on top of all that :) <harlowja> ontop of nicira? <harlowja> ;) <JayF> fwiw our first major cloud-init change was to stop excluding disk partitions from consideration when looking for configdrives <JayF> harlowja: today, no actually :( $vendor_reasons <harlowja> ya, i know about some of that i think ;) <JayF> We <JayF> We've blogged about some of it in various places <harlowja> ya, i just start to wonder if this is really a good way to go down <harlowja> all of yahoo typically gets installed in /home/y/ and that really has not turned out so well over the years <JayF> hah :) <harlowja> to much packages that forget to get managed that someone forked to adjust to fit into /home/y... <JayF> have you seen/used omnibus installed chef? <harlowja> not personally, some other people are <JayF> https://github.com/opscode/omnibus <JayF> as a pattern I don't think this is bad <JayF> kinda an uglier fork of the container pattern, really <JayF> just ship a package, with all it's deps shoved into a dir away from the rest of the os <harlowja> ya, i'm not sure what yahoo is replacing it with (something chef afaik) <JayF> it's ugly I'm sure when you get to the level of installing entire sub-operating systems in ~y/ <harlowja> yup <JayF> but your configuration system (be it chef, cloud-init, whatever) being able to install and run regardless of what OS deps are installed <JayF> could be a valuable thing <JayF> again sorta goes to the world view of a tool like cloud-init being 'out of band' similar to a hypervisor... even though obviously it's not :) <harlowja> ya, i'd be +2 to cloud-init in the kernel <harlowja> like kvm <harlowja> lol <harlowja> i'm sure linus would be fine with that <JayF> HAH <JayF> but you get the general worldview I'm looking with? <harlowja> ya <harlowja> i do <harlowja> although i still have mixed feelings about it, knowing past experiences :-P <harmw> harlowja: you broke my fbsd code! <JayF> the ability to configure the image to utilize $cool_things in my cloud means I need to be able to update cloud-init rapidly as I build $cool_things <harlowja> harmw i might have, ha, who knows <harmw> my branch was working, but trunk now doesn't <harlowja> JayF ya, sure, thats just a slipper slope of becoming your own distro ;) <harlowja> harmw i blame smoser <harlowja> lol <harmw> :P <JayF> and while I don't expect that long-term to be a 'fork' as it is right now... I do expect to continue to want to run pretty close to 'master' cloud-init ... especially when talking about versions shipped in old (>1y old) distros <JayF> harlowja: heh, we'd not be A distro... we'd be a fork of /every/ distro which is why I'm talking to you guys upstream trying to solve the problem in a better way for everyone than just me doing something on my own <harlowja> isn't that called the 'JayF distro' (with description being a ' a fork of /every/ distro') <harlowja> lol <JayF> hah <JayF> It's called coroes <harlowja> but better! <JayF> *coreos <harlowja> lol <harlowja> jayfos <JayF> and all my 'forks' are containers <JayF> dude if I had my own distro <JayF> it'd be called Old OS * JayF runs oldos.org <harlowja> lol <harlowja> nice <harmw> btw harlowja I put an example in that bugrport <harlowja> harmw that log looks fine :-/ <harlowja> 'Using distro class <class 'cloudinit.distros.freebsd.Distro'' ? <harlowja> looks like its trying the openstack one <harmw> 2014-09-02 19:47:06,862 - importer.py[DEBUG]: Failed at attempted import of 'freebsd' due to: No module named freebsd <harmw> 2014-09-02 19:47:06,892 - stages.py[DEBUG]: Using distro class <class 'cloudinit.distros.freebsd.Distro'> <harlowja> ya, look at the line after that <harlowja> its basically logging teh attempts <harlowja> ya, perhaps i should shutup that log <harmw> i posted another one <harmw> nah wait, let me post one with specifying the datasource in cloud.cfg <harmw> Ill do that later on <harlowja> kk <harlowja> i'm gonna shutup that log that says failed imports <harlowja> to confusing <harlowja> u aren't the first to say wtf it failed importing <harlowja> when it really didnt, ha <harmw> yea, Ill try and find out why the F fbsd is failing on me right now with trunk code <harlowja> kk <harlowja> JayF anyways, lets see what smoser thinks, he's from more of the world of distro-land than i am <harlowja> yahoo i know is trying to move forward with stuff like docker and all, so i can see how it might all work out <JayF> I am trying to move forward with stuff like docker and all :) <JayF> but I have to support whatever reasonable patterns my customer wants <JayF> s/customer wants/customers want/ <harlowja> ya, although sometimes customer not doing the right thinkg ;) <harlowja> *thing <JayF> that's where the 'reasonable' part comes in :) <harlowja> ;) <smoser> harmw, i'm being asked for cirros 0.3.3 with mtu fix. <harmw> don't we have that already? <harmw> the fix, that is <harmw> or is that to a pending merge? <smoser> i forget. i thought maybe i had it with other changes. let me look if we can easily do a 0.3.3 <smoser> that has it. <harmw> there is some code from me (?) in LP to adress this <harmw> udhcpc wrapper stuff <harmw> smoser: https://bugs.launchpad.net/cirros/+bug/1301958 <smoser> right <smoser> +## currently disabled as it depends on busybox and buildroot <smoser> +## version numbers (in the patch paths). <smoser> +## note, that without this the cirros-udhcpc is inert, but unoffensive <smoser> that was why it was non-trivial <harmw> ahyes, you had to upgrade buildroot first <harmw> hmgrr, setting the hostname is broken in my fbsd code... it doesn't set what it got from metadata, but instead re-uses `hostname`, or something <harmw> ah, so datasource.get_hostname() is returning that <harmw> bingo: why is it entering this... if self.metadata or 'local-hostname' not in self.metadata: <smoser> later all. i have to run. <gholms> o/ <harmw> harlowja: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/1000.1.1/cloudinit/sources/__init__.py <harmw> I believe that has brutally broken the setting of hostnames <harmw> atleasy in my current testing of the fbsd module <harmw> since I just confirmed to have a perfectly fine hostname (host.bla.tld) inside self.metadata['local-hostname'] <harmw> so please revert that smoser or harlowja :) <harlowja> ya, seems like it could <harmw> JayF: you broke it :p <harlowja> harmw lets see what JayF thinks, i wonder if that was just a mistake <harmw> I'm guessing thats a yes :) <harlowja> me to <JayF> wait what <harmw> oh well, it's always nice to gte the oppertunaty to dive in to the inner workings of c-i :P <harlowja> ;) <JayF> oh man I have a handful of changes like that :( <harmw> lets hope your hands are small, shall we :P <JayF> Ooooh, I see how this one changes the logic <harlowja> pretty sure its 'if not self.metadata or 'local-hostname' not in self.metadata: ' <harlowja> or supposed to be ^ <JayF> pep8 screams about that <harlowja> odd <harmw> the old line was fine though, just reverted it locally and *everything* just works now :) <JayF> harmw: make pep8 will fail though, I presume :( * JayF might be too used to being able to trust unit tests <harmw> don't know, I don't have alle the test tools in this instance to verify <harlowja> let me try <harlowja> harmw JayF https://code.launchpad.net/~harlowja/cloud-init/fixer-up/+merge/233126 <harlowja> also https://code.launchpad.net/~harlowja/cloud-init/better-errors/+merge/233125 <harlowja> seems like pep8 doesn't complain about 233126 <harlowja> and retains the same old logic <JayF> gimme one sec, fixing a network issue <JayF> should we also write a check to catch this instance? <JayF> s/check/test/ <harlowja> probably <JayF> if you say pep8 works, then +1 to the change <harmw> harlowja: 126 is spot on <harlowja> ya, (cloud-init)harlowja@getlookcrowd[0]:~/dev/os/cloud-init $ pep8 cloudinit/sources/__init__.py <harlowja> (cloud-init)harlowja@getlookcrowd[0]:~/dev/os/cloud-init $ <harlowja> no errors/complaints <harmw> god, and this only took 2 precious hours of my tonight-time.. <JayF> harmw: :( I'm sorry man <harmw> and you should! <harmw> :p <harmw> nah, I've seen worse <harmw> harlowja: you're merging this? or do you need permission from the supreme uber godlike master wizard? <harlowja> harmw i can merge, although i'll just let smoser to, where'd he go <harlowja> i usually just delegate to him ha <harmw> :> <harlowja> :) <harmw> well, other than this the fbsd code works btw. Having it set the hostname and adding a user+ssh key wrks just fine <harlowja> cool <JayF> I can't pull this right now, merge it if you think it's right <JayF> sorry :( dealing with local network stuff <harlowja> ya, i'll let smoser pull it in unless its so critical can't wait <harlowja> then i'll try to remember the merge stuff, haha <JayF> harmw: we were just talking around here the otehr day about how neat it'd be to have fbsd support :) <JayF> harmw: (here=rackspace onmetal) #cloud-init 2014-09-03 <harmw> JayF: cool :) <harmw> onmetal.. so that means the ironic (sub)project, right? <harmw> i've been wanting to check that out, someday :) <harlowja_at_home> harmw, i believe onmetal is the rackspace product that uses ironic (probably +- some other rackspace glue) <harlowja_at_home> but i might be wrong to ,haha <harmw> haha <harmw> but yes, I think youre right :) <harmw> isn't it a bit late for you btw? <JayF> harmw: yeah, myself and many others on my team are active in Openstack Ironic :) <JayF> and we don't have that much other rackspace glue there... just lots of patches/features that are pending merge upstream <harmw> JayF: cool <harmw> smoser: PING <smoser> harmw, hey. <harmw> ah great <harmw> we need you to merge something :P <harmw> (since, why else would we need you) <smoser> exactly <harmw> smoser: https://code.launchpad.net/~harlowja/cloud-init/fixer-up/+merge/233126 <harmw> that one <smoser> harmw, done. <smoser> sorry. <smoser> :-( <harmw> haha np <harmw> and thanks <harmw> I'm working on 2 fixes btw, hopefully you can add those as well <harmw> smoser: https://code.launchpad.net/~harmw/cloud-init/freebsd-fixes/+merge/233247 <smoser> harmw, so does that acutally work ? <smoser> writing to that sudoers path ? <harmw> yup <smoser> does it work as in sudo reads it ? <harmw> yes <smoser> this all feels like slackware <harmw> welcome to fbsd :P <smoser> and reminds me of a simpler time in 1998. <harmw> ah yes, 1998... reminds me of highschool :> <RaginBajin> smoser I've been working on the changes you recommened to me in https://code.launchpad.net/~josephbajin/cloud-init/freebsd-configdrive/+merge/231214 <RaginBajin> and I got one of this fixed, but I honestly have no idea how to fix the second <smoser> RaginBajin, ok. i can maybe help in 30 minutes or so. <smoser> sorry, in a call now <RaginBajin> Take your time.. I've been super busy with some other stuff lately, which is why I have disappeared for a little <smoser> RaginBajin, maybe you didn't push ? <RaginBajin> yeah let me do that one. <smoser> last commit is shown as 2014-08-18 <RaginBajin> ok just pushed the update I made <harlowja> hiren_ yt <RaginBajin> it removes the lazy mode for umount <harlowja> hiren_ the freebsd stuff afaik merged, so if u wanted to try it out maybe harmw can give some basic instructions? <harlowja> oh, smoser also https://code.launchpad.net/~harlowja/cloud-init/better-errors <harlowja> more log cleanup <smoser> harlowja, danke <harlowja> np <harlowja> that one was noisy and confusing <harlowja> so fixed it, lol <hiren_> harlowja: ah, let me get to it later today or tomorrow <hiren_> thanks <harlowja> np <RaginBajin> smoser, I'm going to hop back on later or tomorrow. I got to run here in a few. We can talk about my changes then. too much work not enough time <harmw> smoser: think you can merge that last bit as well? <smoser> harmw, will ead in a bit. sorry <harmw> ah great, nice :) <harmw> smoser: merge.. ;) <smoser> harmw, i'm sory. time just goes away. <harmw> hehe yea i know :) <harmw> don't we all have that damn problem <harlowja> not me, ha #cloud-init 2014-09-04 <mhroncok> smoser: hi, got a minute? <smoser> mhroncok, whats up? <mhroncok> smoser: I wan to talk with you about cloud-init and Python 3 <mhroncok> smoser: cloud-init is the last thing in Fedora cloud stack, that doesn't support Python 3 <mhroncok> smoser: and we would like to make it happen <mhroncok> how can we help? <smoser> its on a list, and it should have been done alrady. <smoser> i'm open to patches for that. we've done some work in that direction (dropping boto and cheetah recently) <mhroncok> there are several relevant issues opened, but it seems nothing is happening, so we we would be happy to help with patches - however we are not sure what should we focus on first <mhroncok> BTW boto now supports Python 3 <mhroncok> I've seen this: https://code.launchpad.net/~harlowja/cloud-init/changeable-templates/+merge/208994 <mhroncok> so now it should only be about cloud-init itself? <smoser> i didn't know about boto and python3, thats good. yeah, it should be only cloud-init itself. <mhroncok> is there any branch for python 3 porting or stuff liek tyhat, or we should just start with trunk? <mhroncok> s/liek tyhat/like that/ <smoser> trunk. <smoser> harlowja_away, may have taken some further amy08@example.org. <mhroncok> smoser: ok, thanks for info <smoser> i think it makes sense to get to python3 support in cloud-init. <smoser> there is some discussion about doing a cloud-init 2.0, which
{'channel': 'cloud-init', 'month': 9}