[13:57] <openstackgerrit> Claudiu Popa proposed stackforge/cloud-init: Add an API for loading a data source  https://review.openstack.org/209520
[15:08] <Seth_Kar_> Hey all, can anyone assist me with debugging chef on CentOS 7? I've already figured out to turn off SELinux, but if I run cloud-init --debug single -n chef it doesn't give any information. If I reboot I just get an error saying the cc_chef python module failed
[15:08] <Seth_Kar_> Is there any way to increase this verbosity during the reboot, or a way to properly re-run cloud-init after I have a shell?
[15:28] <smoser> Seth_Kar_, you likely have something in /var/log/cloud-init.log
[15:28] <smoser> look for WARN
[15:30] <smoser> if you do not, then edit /etc/cloud/cloud.cfg.d/05_logging.cfg and comment out the line ' - [ *log_base, *log_syslog ]'
[15:30] <smoser> you should also have output in /var/log/cloud-init-output.log
[15:30] <Seth_Kar_> smoser: I have the following WARN errors
[15:30] <Seth_Kar_> Aug 31 17:16:35 localhost cloud-init: 2015-08-31 17:16:35,047 - cloud-init[WARNING]: Stdout, stderr changing to (| tee -a /var/log/cloud-init-output.log, | tee -a /var/log/cloud-init-output.log)
[15:30] <Seth_Kar_> Aug 31 17:16:35 localhost cloud-init: Cloud-init v. 0.7.5 running 'modules:config' at Mon, 31 Aug 2015 15:16:35 +0000. Up 6.15 seconds.
[15:30] <Seth_Kar_> Aug 31 17:16:35 localhost cloud-init: 2015-08-31 17:16:35,509 - util.py[WARNING]: Running chef (<module 'cloudinit.config.cc_chef' from '/usr/lib/python2.7/site-packages/cloudinit/config/cc_chef.pyc'>) failed
[15:31] <Seth_Kar_> smoser: The same error is in /var/log/cloud-init-output.log
[15:31] <Seth_Kar_> Is there a way to manually run the chef recipe with additional debugging?
[15:34] <smoser> there should be some message about what failed, or a stack trace or something.
[15:35] <smoser> 'run the chef recipe' ?
[15:37] <Seth_Kar_> There is no message, it just says failed
[15:37] <Seth_Kar_> The running chef error is the only error I get
[15:38] <Seth_Kar_> Can I call the python script from the shell to debug?
[15:42] <smoser> as you did, 'single -n chef'
[15:42] <smoser> it really should have a sack trace or some thing .
[15:42] <smoser> can you pastebin the cloud-init.log and cloud-init-output.log ?
[15:42] <smoser> i realize you might potentially have sensitve infor ther
[15:44] <harlowja_at_home> i also have messed with the chef stuff at one point, so let me know to :)
[15:44] <harlowja_at_home> but usually its always smoser fault
[15:44] <harlowja_at_home> lol
[15:48] <openstackgerrit> Merged stackforge/cloud-init: Add an API for loading a data source  https://review.openstack.org/209520
[15:50] <smoser> claudiupopa, ^ that merged, please do add the 'version=' thing.
[15:55] <claudiupopa> thanks!
[16:00] <Seth_Kar_> smoser: harlowja_at_home: https://gist.github.com/Seth-Karlo/266ecc9d5618f0b5b9cf
[16:01] <harlowja_at_home> hmmm
[16:01] <harlowja_at_home> any idea whats in '/var/log/cloud-init-output.log'?
[16:01] <Seth_Kar_> If I run it on CentOS 6 I get a different error
[16:01] <Seth_Kar_> Sure, hang on
[16:01] <smoser> and /var/log/cloud-init.log .
[16:01] <smoser> what you did above makes perfect sense that it *should* show stuff.
[16:01] <smoser> but... get /var/log/cloud-init.log
[16:01] <Seth_Kar_> Only two lines in /var/log/cloud-init-output.log
[16:02] <Seth_Kar_> 2015-08-31 17:59:53,589 - cloud-init[DEBUG]: Logging being reset, this logger may no longer be active shortly
[16:02] <harlowja_at_home> hmmm
[16:02] <Seth_Kar_> Cloud-init v. 0.7.5 running 'single' at Mon, 31 Aug 2015 15:59:53 +0000. Up 2603.45 seconds.
[16:02] <Seth_Kar_> No change to /var/log/cloud-init.log
[16:02] <harlowja_at_home> bb, irc meeting
[16:02] <Seth_Kar_> Np
[17:11] <harlowja> k, back
[17:14] <smoser> Odd_Bloke, you have a minute ?
[17:14] <smoser> i'm trying to get my changes for reporting that i've most recently have in curtin into c loud-init (so you can be happy and they'll be synced).
[17:38] <natorious> are you guys doing weekly or bi-weekly openstack meetings for this proj?
[18:16] <smoser> natorious, we have a weekly meeting at 14:00:00 UTC
[18:17] <smoser> in this channel.
[18:17] <natorious> smoser: ty sir.  Added to cal
[18:17] <natorious> which day though lol?
[18:19] <smoser> oh silly me
[18:19] <smoser> wednesday
[18:22] <natorious> there is another linux dev from rax that will be helping out too.  I'll pass this info along :)
[18:23] <jlambert121> i'm working on setting cloud-init up on a centos7 AWS image.  i'm trying to figure out how to disable the default centos yum repos (we have internal mirrors).  i can add/configure new repos without problem, but i can't seem to get [base] "enabled: false" set
[18:24] <jlambert121> if someone has an example link/insight it would be greatly appreciated
[20:07] <gamename> hi guys.  I'm trying to figure out what "disable-ec2-metadata" does.  Should I take that out if I want to use metadata?
[20:57] <smoser> gamename, it defaults to false
[20:58] <smoser> all that does is run the config module
[20:58] <smoser> the config module, if it sees 'disable_ec2_metadata: true'
[20:58] <smoser> then it will null-route the metadata service
[20:58] <smoser> that way if you had sensitive data there, no one could see it without rooting system first.
[20:58] <smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L249
[20:59] <smoser> jlambert121, maybe harlowja can say. i have to run, sorry.
[20:59] <jlambert121> smoser: thanks.  i've been banging on this all day without luck.  trying to get a bootcmd of 'rm -f /etc/yum.repos.d/*' to work right now, but it's an ugly hack
[21:00] <jlambert121> harlowja: if you have any other thoughts that'd be appreciated
[21:00] <gamename> smoser: Thanks!
[21:02] <gamename> smoser: "package_update"  defaults to "true". Correct?
[21:13] <harlowja> jlambert121 smoser ya, pretty sure that should disable the route stuffs
[21:14] <jlambert121> harlowja: i was trying to figure out how to modify the default yum repos on an image - thoughts?
[21:15] <harlowja> i think https://github.com/stackforge/cloud-init/blob/0.7.x/doc/examples/cloud-config-yum-repo.txt#L2 can be used to overwrite existing ones, but haven't tried it in a while
[21:15] <harlowja> or u can use the write files approach to write out new files
[21:15] <harlowja> https://github.com/stackforge/cloud-init/blob/0.7.x/doc/examples/cloud-config-write-files.txt (for example)
[21:17] <jlambert121> harlowja: writing new ones works great with the yum plugin, but i can't seem to modify existing ones with it
[21:17] <harlowja> hmmm
[21:17] <harlowja> ya i guess https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/config/cc_yum_add_repo.py#L74 is preventing that
[21:18] <jlambert121> on centos there are 4 repos defined in a CentOS-Base.repo file which seems to be confusing it
[21:19] <jlambert121> [base] is one of the repos - if i set up a repo named base with cloud-init it'll create a base.repo file, not modify the existing one (which doesn't seem like bad behavior), but i somehow need to get rid of the old [base] repo then
[21:20] <jlambert121> i was just going to try adding a 'rm -f /etc/yum.repos.d/*.repo' to the bootcmd and see if i could hack it up that way, but doesn't "feel" quite right
[21:20] <harlowja> ya, it's probably better to do something else, more native, but i'd just remove the specific repo files u know u want to overwrite for now
[21:20] <harlowja> the code  @ https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/config/cc_yum_add_repo.py#L71 should probably allow overwrite
[21:21] <harlowja> vs not
[21:21] <jlambert121> yeah, if repo_id is found, just modify the repo_config for that id
[21:22] <jlambert121> that was the behavior i expected anyway
[21:22] <harlowja> ya, when i created that (think it was me) probably was just being conservative
[21:22] <jlambert121> want me to open a GH issue for it? (it's beyond me to change)
[21:22] <harlowja> https://bugs.launchpad.net/cloud-init/ instead, GH issues will get automatically closed
[21:23] <harlowja> GH is just a mirror
[21:23] <jlambert121> ahh, ok - i'll do that.  thanks for the help
[21:23] <harlowja> jlambert121 its never beyond u to change it ;)
[21:23] <harlowja> never accept defeat, ha
[21:24] <jlambert121> harlowja: very true as i tell others with projects i ask for PRs on.  I should state it as: in the near future i'm not going to have time to learn python and make this change, but some day :)
[21:24] <harlowja> ;)
[21:24] <harlowja> so like the day after tommorow then?
[21:24] <harlowja> ha
[21:24] <jlambert121> yeah, something like that
[21:25] <harlowja> :)
[21:25] <jlambert121> after my 4 "number one priorities" at $dayjob get done and 6 number ones at $home :)
[21:26] <gamename> hi guys.  How do I check what the default of "package_update" would be?
[21:27] <harlowja> check /etc/cloud/cloud.cfg
[21:27] <harlowja> https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/config/cc_package_update_upgrade_install.py#L51 is all the keys that module uses
[21:27] <harlowja> so if there is an entry for those keys in there, thats the default
[21:27] <harlowja> jlambert121 well u need to sleep less then, more doing #number ones
[21:28] <harlowja> although don't to many number #2(s); if u do that alot u may want to see a doctor
[21:28] <gamename> harlowja: entry in where?
[21:28] <harlowja> the config file in the VM @ /etc/cloud/cloud.cfg
[21:28] <harlowja> thats typically where that stuff is stored
[21:30] <gamename> harlowja: So, if there is a mention of a value in /etc/cloud/cloud.cfg, then that is the default?  Wouldn't that mean that /etc/cloud/cloud.cfg is not a config file at all, but a kind of key/value template file?
[21:30] <gamename> confused.
[21:31] <harlowja> depends on what u typically call a config file
[21:31] <harlowja> to me a config file is things with settings that affect how some program runs
[21:31] <harlowja> if thats key/values, binary, digits, if they affect how a program is ran, its config
[21:32] <gamename> harlowja: So, what if there is no mention of a key in /etc/cloud/cloud.cfg? What then?  Does it take a default value then?
[21:33] <harlowja> right, so then it starts merging 'configuration' together
[21:33] <harlowja> to form a final config that will be used
[21:34] <gamename> harlowja: Merge the contents of /etc/cloud/cloud.cfg and what else?
[21:34] <harlowja> soooo first its https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/settings.py#L29
[21:34] <harlowja> then /etc/cloud/cloud.cfg  merges into that
[21:34] <harlowja> then things in /etc/cloud/cloud.cfg.d i think
[21:35] <harlowja> then userdata and metadata get merged in
[21:35] <harlowja> oh https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/helpers.py#L258
[21:35] <harlowja> i think thats the list, from what i remember
[21:36] <gamename> harlowja: ok.  So, how is the default for a given value, in this case "package_update", determined?  If that key isn't mentioned in /etc/cloud/cloud.cfg where is the default set?
[21:37] <harlowja> the code that those config then can set a default if it so wants to
[21:37] <harlowja> https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/config/cc_package_update_upgrade_install.py#L51
[21:37] <harlowja> thats the code, anything touching 'cfg' variable name there is extracting stuff
[21:37] <harlowja> *extracting stuff from the merged config
[21:39] <gamename> harlowja: So, you're saying the only time there is a value for a key is when it is specifically set?
[21:39] <harlowja> or the code that uses that key decided to set some default if it doesn't find a key
[21:39] <harlowja> ie 'pkglist = util.get_cfg_option_list(cfg, 'packages', [])'
[21:39] <harlowja> that sets it to a empty list if its not found
[21:40] <harlowja> now u may say this could be done via another way, but ya, thats the current way
[21:40] <gamename> harlowja: ok.  How can I tell if "package_update" ever gets a value set for it?
[21:41] <harlowja> i think u can activate the debug module
[21:41] <harlowja> https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/config/cc_debug.py will dump out the end cfg
[21:41] <harlowja> if your version of cloud-init has that module
[21:42] <gamename> harlowja: ok. So I have to turn on debug to tell what a default value is. Got it.
[21:42] <harlowja> well and u have to look at the code for what it does when values aren't found in that config
[21:43] <gamename> harlowja: Debug may not supply the answer?
[21:43] <harlowja> nope
[21:43] <harlowja> debug will show u the initial config
[21:43] <harlowja> that is given to each module, then u look at the code
[21:44] <gamename> harlowja: Doesn't sound like its worth the time.  Nevermind.
[21:44] <harlowja> ok
[21:46] <gamename> smoser: Do I really need to run debug and scan the code just to find out the default of a keyword? wow...
[21:47] <harlowja> there are multiple config sources, so its not just as simple as u would want it