[00:28] <zero_shane> hi all - relatively new to cloud-init, but I haven't been able to find an answer to this yet ... does cloud-init support setting variables which can be used subsequently in templates - example FOO=bar, then within a template {{FOO}} for expansion ?   I'd want to apply this in cloud.cfg, allowing me to set more generic/templatized templates, that can be tweaked based on the base cloud.cfg information
[00:52] <smoser> harlowja_, coul dyou merge with trunk?
[00:53] <smoser> there is one conflict in debian.py
[01:09] <smoser> harlowja_, and if you are around...
[04:22] <smoser> harlowja_, i merged for yhou.
[04:23] <smoser> all-in
[04:23] <smoser> and uploaded to yakkety
[04:23] <smoser> so you better not have messed it up!
=== rharper` is now known as rharper
[10:54] <coolshiva123> hi team
[10:54] <coolshiva123> need a help with cloud-init on centos
[11:00] <coolshiva123> anyone there?
[11:05] <Odd_Bloke> coolshiva123: Ask your question, and if anyone knows the answer then they might respond. :)
[11:28] <coolshiva123> I have a centos7 template and i have some scripts in per-boot
[11:28] <coolshiva123> the cloud-init fails to execute them
[11:28] <coolshiva123> i have a clean cloud-init.log
[11:28] <coolshiva123> and cloud-init-output.log
[11:28] <coolshiva123> anyway to troubleshoot why cloudinit ignores script in per boot?
[11:58] <smoser> coolshiva123, are they executable ?
[11:59] <smoser> you should be able to run
[11:59] <smoser>  sudo cloud-init single --name=scripts-per-boot --frequency=always
[11:59] <smoser> and with '--debug' you'll get mroe output to screen.
[12:17] <coolshiva123> hi
[12:18] <coolshiva123> these scripts are definitley executable
[13:06] <coolshiva123> [root@bceglc298 per-boot]# cloud-init single --name scripts-per-boot --frequency always --debug usage: cloud-init [-h] [--version] [--file FILES] [--debug] [--force]                   {init,modules,query,single} ... cloud-init: error: unrecognized arguments: --debug
[15:43] <smoser> coolshiva123, --debug has to go to cloud-init not to 'single'
=== Toger_ is now known as Toger
[16:49] <harlowja_> smoser thx boss
[16:49] <harlowja_> i was gonna merge today, but i guess u did
[16:49] <smoser> yeah, i fixed that.
[16:49] <smoser> pylint and six is obnoxious
[16:49] <harlowja_> lol
[16:49] <smoser> pylint --errors-only is really helpful
[16:49] <smoser> but six really tricks it out
[16:49] <smoser> on curtin we run --errors-only and it catches so many things
[16:49] <harlowja_> cool
[16:50] <smoser> but here it has a bunch of false positives
[16:50] <smoser> maybe 12
[16:50] <harlowja_> smoser  i was thinking, do u still want daemon support in cloud-init ? something that uses pyudev for example to get notified of hardware changes and activates modules?
[16:50] <harlowja_> that was a cloud-init 2.0 thing, but doesn't seem so hard to do it ...
[16:51] <smoser> so..
[16:51] <smoser> plans for cloud-init in near term.
[16:51] <smoser> a.) get 0.7.8 release that works for network configuration on centos on NoCloud and ConfigDrive
[16:51] <smoser> b.) get to git
[16:52] <smoser> c.) support getting network configuration from network'd datasources
[16:52] <harlowja_> k
[16:52] <smoser> ie, in he OpenstackMetadata
[16:52] <smoser> so tha'td mean in the local stage, we'd bring up networking for the localnet and check 169.254.169.254
[16:53] <smoser> and then say "oh look, my networking!"
[16:53] <harlowja_> smoser u might also want to comment on  https://review.openstack.org/#/c/324054/
[16:53] <harlowja_> i'll eventually start a openstack-dev ML about that if it doesn't move
[16:53] <harlowja_> its sorta whacky to say 'the bug is there, and we aren't gonna change it, to bad...'
[17:00] <smoser> its not really a bug
[17:00] <smoser> just stupid
[17:00] <harlowja_> :-p
[17:00] <smoser> chaing the format of an opaque string is not breaking abi
[17:00] <harlowja_> agreed
[17:01] <smoser> it would seem like a change in EC2 from :
[17:01] <smoser>  i-abcdefg
[17:01] <smoser> to
[17:01] <smoser>  i-abcdefgh
[17:01] <harlowja_> omg
[17:01] <harlowja_> how dare u
[17:01] <harlowja_> lol
[17:01] <smoser> (ie, they realized at some point that 6 chars was not enough)
[17:01] <smoser> this is actually true
[17:01] <harlowja_> nice
[17:01] <harlowja_> lol
[17:01] <smoser> and it actually *did* break things (stupid things)
[17:01] <harlowja_> stupid things be stupid
[17:01] <smoser> that assumed 8 chars (or whatever it was) was how long that thing should be
[17:02] <smoser> all that MP is doing is replacing the internal (host) interface name
[17:02] <smoser> with another interface name, right?
[17:02] <smoser> as long as it keeps the value as consistent as the previous value (not changing on reboot, or stop/start) then it would surely seem fine to me
[17:09] <harlowja_> ya, seems fair to me
[17:11] <harlowja_> smoser comment on that review :-P
[17:11] <smoser> on it
[17:14] <smoser> harlowja_, how do i review ?
[17:14] <harlowja_> press 'A'
[17:14] <smoser> i'm logged in... but i dont see a text area or anhyting
[17:14] <harlowja_> ya, the GUI changed
[17:15] <harlowja_> lowercase 'a'
[17:15] <smoser> man.
[17:15] <smoser> that is *worse* than it used to be!
[17:15] <smoser> which is pretty technically impressive
[17:15] <harlowja_> def
[17:15] <harlowja_> no disagreements from me, it got weirder
[20:52] <sather> I'm trying to play around with cloud-init modules. I want to write a simple handler that takes the user-data passed in an EC2 instance and writes it to a yaml file.
[20:53] <sather> what datatype is _cfg?
[20:54] <sather> in the handle function `def handle(name, _cfg, _cloud, log, _args):`
[21:01] <harlowja_> sather i believe its just a dict
[21:02] <harlowja_> cloud is just a http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/cloud.py#L43 object
[21:02] <harlowja_> and args are i forget, lol
[21:52] <harlowja_> where'd the amazon guy go
[21:52] <harlowja_> damn, we lost him already :(
[22:06] <sather> harlowja_: thanks
[22:40] <smemsh> smoser: i see you maintain cloud-init for ubuntu.  surprisingly, in ubuntu-14 cloud images, network config via cloud-init (0.7.5) does not work because "ifup: failed to open lockfile /run/network/ifstate.lo: No such file or directory" during first boot.  is this worth filing a bug or never get looked at due to age of release?
[22:41] <smemsh> smoser: or maybe it's packaging error for cloud images and should not go to cloud-init package?
[22:44] <sather> could someone help me understand this error:
[22:44] <sather> __init__.py[WARNING]: Unhandled no
[22:44] <sather> n-multipart (text/x-not-multipart)
[23:00] <sather> realized I should be using write_files module
[23:09] <smemsh> the snippet in cloud-init-container.conf that does mkdir -p /run/network needs to also be done for non-containers or ifup --all fails
[23:15] <smemsh> it runs _bring_up_interface() before network-interface.conf / network.conf have run apparently, which fails on ubuntu
[23:15] <smemsh> due to mk /run/network
[23:15] <smemsh> no
[23:17] <smemsh> i'll bet the tests do not try static ip setup, only dhcp and that probably works
[23:30] <smemsh> yeah, i can see, init-local banner, then ifup --all fails, then cloud-init-nonet runs (which blocks waiting for static), and finally static networking comes up, which is the one that does the mkdir -p.  so it happens too late, it can never work
[23:33] <smemsh> how do i inject runcmd in there to mkdir -p? network comes from metadata, it looks like it runs before anything from user-data
[23:58] <sather> grr...boss says we can't use write_files directive
[23:58] <sather> because we need to not touch the metadata file
[23:58] <sather> :(