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