[01:46] <masber> good morning, is this the right place to talk about cloud-init? I have an issue I would like to discuss
[05:53] <smoser> masber, it is the right place.
[05:53] <smoser> but i'm about to go afk.
[05:54] <masber> oh
[05:55] <smoser> masber, i'm US/Eastern.
[05:56] <masber> ok im Australia/Eastern
[05:56] <smoser> file a bug and paste a link here https://bugs.launchpad.net/cloud-init/+filebug
[05:56] <smoser> i'm going afk. good night.
[05:57] <masber> ok good night
[13:59] <dgarstang> Is there any way to pass the output of a script to the hostname to be set by cloud-init ?
[14:25] <Hawson> Good $time_of_day everyone
[14:34] <Hawson> I'm running version 0.7.5-10 (the version packaged with Centos 7), trying to provision some AWS instances.  The instances come from a custom AMI, but there are a few things that need to happen after the instance is launched.  Specifically, I'm tryting to run some commands via "runcmd", but I can't find any evidence that they actually get run.
[14:35] <powersj> rharper: https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init/build/562061/
[14:35] <Hawson> the /var/lib/cloud/instance/<instanceID>/scripts/runcmd file is properly created, and has the expected contents....
[14:35] <rharper> thx
[14:35] <Hawson> but it never seems to actually tun.
[14:35] <powersj> smoser: https://copr-be.cloud.fedoraproject.org/results/%40cloud-init/cloud-init/epel-7-x86_64/00562061-cloud-init/root.log.gz
[14:35] <Hawson> grep -i runcmd /var/log/cloud*
[14:35] <Hawson> also turns up nothing
[14:36] <smoser> Hawson, hey.
[14:37] <smoser> i suspect that the cloud-final systemd job is not running
[14:37]  * Hawson tips his hat to smoser 
[14:37] <Hawson> I checked that, actually
[14:37] <rharper>  https://copr-be.cloud.fedoraproject.org/results/%40cloud-init/cloud-init/epel-7-x86_64/devel/repodata/repomd.xml
[14:37] <Hawson> and it looks like it is...
[14:37] <Hawson> systemd "says" it ran successfully....
[14:38] <smoser> Hawson, i assumethere isnt much in /var/log/cloud* right ?
[14:38] <Hawson> correct, not much in the logs
[14:38] <Hawson> Jun  6 21:55:08 localhost cloud-init: Cloud-init v. 0.7.5 running 'modules:config' at Tue, 06 Jun 2017 21:55:08 +0000. Up 9.64 seconds.
[14:38] <Hawson> Jun  6 21:55:09 localhost cloud-init: Cloud-init v. 0.7.5 running 'modules:final' at Tue, 06 Jun 2017 21:55:09 +0000. Up 10.18 seconds.
[14:38] <Hawson> Jun  6 21:55:09 localhost cloud-init: Cloud-init v. 0.7.5 finished at Tue, 06 Jun 2017 21:55:09 +0000. Datasource DataSourceEc2.  Up 10.39 seconds
[14:38] <rharper> ImportError: No module named six
[14:38] <rharper> https://copr-be.cloud.fedoraproject.org/results/%40cloud-init/cloud-init/epel-7-x86_64/00562061-cloud-init/build.log.gz
[14:38] <Hawson> I should note that one of the scripts I want to run is expected to take many seconds (upto a minute or two) to complete
[14:39] <Hawson> so for it to finish is about a quarter second is...suspicious. :)
[14:40] <Hawson> bootcmd: operations *do* run, however
[14:41] <powersj> smoser: rharper: this is the spec file I used to get those builds to go: https://git.launchpad.net/~powersj/cloud-init/tree/packages/redhat/cloud-init.spec?h=redhat-spec
[14:43] <smoser> Hawson, /etc/cloud/cloud.cfg.d/05_logging.cfg
[14:43] <smoser> int hat file , can you comment out
[14:43] <smoser> - [ *log_base, *log_syslog ]
[14:43] <smoser> (just add a '#' at the beginning)
[14:44] <smoser> then rm -Rf /var/lib/cloud* /var/log/cloud-init*
[14:44] <smoser> and reboot
[14:44] <Hawson> There's a stanza for "_log:"
[14:44] <Hawson> do anything with that?
[14:45] <smoser> at the bottom
[14:45] <smoser> log_cfgs:
[14:45] <smoser>  ...
[14:45] <Hawson> _log: is at the top, actually.
[14:45] <smoser> there should be a line like
[14:45] <smoser> - [ *log_base, *log_syslog ]
[14:45] <Hawson> the lines you are talking about are at the bottom
[14:45] <Hawson> already commented out and bouncing
[14:46] <smoser> Hawson, now i understnad your confusion
[14:47] <smoser> "at the beginning". i meant "at the beginning of the line"
[14:47] <Hawson> I understand your confusion at my confusion. :)
[14:47] <Hawson> Anyhow, host is up.  checking logs
[14:47] <Hawson> interesting though--lots more outptu this time around.
[14:48]  * Hawson thinks I should disable syslog in general...
[14:50] <Hawson> not really much better.
[14:50] <Hawson> better logs, but still not actually running the script.
[14:51] <Hawson> a few lines about calling cc_runcmd, writing the actual file, but not actually running them
[14:53] <Hawson> hmmm...
[14:53] <Hawson> 2017-06-07 10:46:44,671 - importer.py[DEBUG]: Looking for modules ['cc_runcmd', 'cloudinit.config.cc_runcmd'] that have attributes ['handle']
[14:53] <Hawson> 2017-06-07 10:46:44,671 - importer.py[DEBUG]: Failed at attempted import of 'cc_runcmd' due to: No module named cc_runcmd
[14:53] <Hawson> 2017-06-07 10:46:44,672 - importer.py[DEBUG]: Found cc_runcmd with attributes ['handle'] in ['cloudinit.config.cc_runcmd']
[14:53] <Hawson> is that....normal?
[14:55] <smoser> Hawson, there is a bug with systemd that coud-init starts writing there before syslog is really "up", so it goes to devnul
[14:55] <smoser> 'runcmd' is not the name of the module that runs that stuff.
[14:56] <Hawson> systemd is stupidly broken?  I'm *SHOCKED*!  Shocked, I say.
[14:57] <Hawson> that's just the module that writes out the script, it seems.... (looking at cc_runcmd.py now)
[14:58] <Hawson> so that brings up the question:  what *does* actually execute the script?
[14:59] <smoser> scripts-user
[15:02] <Hawson> eh....okay.  I don't see any indication of scripts_user exec()ing scripts/runcmd
[15:04] <Hawson> I _do_ see lines like:  "helpers.py[DEBUG]: Running config-scripts-per-once using lock...."
[15:20] <Hawson> smoser: if scripts-user handles the actual exectution, and runcmd merely generates a script, what am I missing to get one to talk to the other?
[15:20]  * Hawson is somewhat confused about the execution flow here.
[15:22] <Hawson> although...https://git.launchpad.net/cloud-init/tree/config/cloud.cfg  implies that runcmd happens in the 'config' stage, not final?
[15:24] <smoser> Hawson..
[15:24] <smoser> sorry.
[15:25] <smoser> so the default config is that the 'runcmd' module runs earlier, but all it does is write files that are executed later by scripts-user
[15:25] <Hawson> Okay.
[15:25] <smoser> can you post /var/log/cloud-init.log and /var/log/cloud-init-output.log
[15:26] <Hawson> So here's a dumb question.... :)
[15:26] <Hawson> I have stanzas for cloud_init_modules:, cloud_config_modules: and clout_final_modules:
[15:26] <Hawson> none of them have runcmd in them....
[15:26]  * Hawson inherited this setup from someone else
[15:28] <smoser> Hawson, well, you need 'runcmd' to read your 'runcmd:' stanza and render that into /var/lib/cloud/instance/per-instance/... (i think thats the path)
[15:29] <smoser> then you also need 'scripts-user'
[15:29] <Hawson> yeah, that's the path
[15:29] <smoser> or you wont *execute* what the other wrote
[15:29] <Hawson> hmm.
[15:29] <Hawson> this may be a timing issue then
[15:30] <Hawson> cloud_https://pastebin.com/gBGMbEVL
[15:30] <Hawson> ehh..
[15:30] <Hawson> https://pastebin.com/gBGMbEVL
[15:30] <smoser> yep
[15:30] <smoser> yeah, those are wrong order
[15:30] <smoser> just move runcmd up
[15:30] <Hawson> Yep.
[15:31]  * Hawson kicks off the AMI baking...
[15:31] <Hawson> The *REALLY* annoying part of this is that what I'm trying to get running is a 100% useless waste of time. :-(
[15:32] <Hawson> and I've spent a lot of time getting it working (not just with cloud-init)
[15:34] <Hawson> ...we build an AMI with packer...that runs puppet...then calls cloud-init after boot.
[15:34]  * Hawson looks around for more bailing wire and duct-tape
[15:35] <smoser> Hawson, i'm sorry that 'runcmd' as the module doesnt actually do the running
[15:35] <smoser> (that is very confusing...)
[15:35] <Hawson> Heh, yeah.  That's kinda confusing.  :)
[15:35] <Hawson> I do appreciate the help though.
[15:36] <smoser> rharper,
[15:36] <smoser> http://paste.ubuntu.com/24801194/
[15:38] <powersj> https://copr-be.cloud.fedoraproject.org/results/%40cloud-init/cloud-init/epel-7-ppc64le/00562449-cloud-init/build.log.gz
[15:38] <powersj> smoser: ^
[15:44] <blackboxsw> %{?systemd_requires}
[15:44] <blackboxsw> per https://fedoraproject.org/wiki/Packaging:Scriptlets
[15:51] <Hawson> woohoo!
[15:51] <Hawson> it's running this [CENSORED] script at boot.
[15:52] <Hawson> awesome
[15:52] <Hawson> kinda
[15:52] <Hawson> the cloud-init bit is awesome.  The script is a steaming pile of [censored]
[15:52]  * Hawson owes smoser a beer
[15:53] <smoser> glad we could help.
[15:53] <Hawson> I do suggest a bit of clarification in the docs though.
[16:08] <rharper> https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init/build/562456/
[16:09]  * rharper crosses fingers
[18:03] <rharper> smoser: http://paste.ubuntu.com/24802038/   specfile template fixes works for el6/el7
[18:17] <powersj> rharper: https://docs.pagure.org/copr.copr/how_to_enable_repo.html#how-to-enable-repo
[18:20] <rharper> https://copr.fedorainfracloud.org/coprs/alonid/yum-plugin-copr/
[18:21] <powersj> yum copr enable @cloud-init/cloud-init
[18:21] <rharper> fancy
[18:31] <rharper> ok
[18:31] <rharper> http://paste.ubuntu.com/24802167/
[18:31] <rharper> that works in a fresh cent7 container
[20:19] <Hawson> can cloud-init fire off a script "in the background"?
[20:19] <Hawson> via runcmd?
[21:04] <rharper> Hawson: I think typical bashism like disown would work (https://askubuntu.com/questions/611968/differences-between-command-disown-and-nohup-command-disown)
[21:09] <Hawson> Hmm..."disown" is a new one to me
[21:50] <smoser> rharper, https://code.launchpad.net/~akaris/cloud-init/+git/cloud-init/+merge/325186
[21:53] <rharper> ack
[22:30] <rharper> larsks: working on the redhat spec in trunk, and for rhel7 seeing this issue https://github.com/tony/tmuxp/issues/111  ;  it appears that setuptools injects 'argparse' in requires.txt but in rhel7 argparse is part of python2.7 already
[22:31] <rharper> Is there an distro bug against setuptools?  I've not found one yet;  I'm thinking of sed'ing out argparse if we're el7 (or if python -c 'import argparse' returns 0)
[22:44] <rharper> looks like it was still in our requirements; but we'll add it into the spec template only for el6 releases; then we can drop it from the requirements;  that should clean things up
[23:34] <larsks> rharper: isn't argparse a part of python 2.7 everywhere?
[23:35] <rharper> it isn
[23:35] <rharper> sorry
[23:35] <rharper> yes, it is
[23:35] <rharper> we 've been dealing with 2.6
[23:35] <rharper> we've got it worked out now;   no longer including it in requirements.txt, and then in specfile for systems using py26, to include the dep as a BuildReq and Req
[23:35] <larsks> Awesome.
[23:35] <rharper> https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init/
[23:36] <rharper> smoser: should be merging the branch to trunk soon (fixing tox) and then we'll have daily trunk builds  up
[23:36] <rharper> definitely look at the specfile template and push any other fixes or issues you see with it;
[23:37] <rharper> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/325192
[23:40] <larsks> I'll take a look!
[23:54] <rharper> larsks: cool, thanks!
[23:57] <rharper> smoser: https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init/build/562649/