[09:23:18] jbond42: hi! :), about 654419, thanks a lot for the review, I have a question there though, when you have some time [09:29:41] dcaro: looking [09:47:47] hmpf... rubocop locally fails complaining that ruby 2.5 is not found... [09:55:14] dcaro: i have responded on the change was there anything elses other then the comments on task? [09:57:24] in relatation to rubocop are you running it via rake or directly and if by rake from which dir? also what version of ruby do you have [10:12:52] jbond42: https://phabricator.wikimedia.org/T271702#6742919 . Turns out we can't avoid that, easiest path forward seems to be to just amend `ferm-status` to ignore that rule [10:15:50] akosiaris: ack thanks ill take a look later today [10:16:13] thanks! [10:17:51] np [10:20:16] <_joe_> dcaro: if you want to run ci tasks locally, utils/run_ci_locally.sh is your friend [10:21:14] <_joe_> ./utils/run_ci_locally.sh runs all tests that CI runs; but it also accepts arguments for rake [10:23:10] <_joe_> ./utils/run_ci_locally.sh --tasks will tell you which tasks are available for your current change [10:31:23] jbond42: nothing else yep, thanks :), about rubocop, I'm running with rbenv, using ruby 2.5.5 (rbenv local 2.5.5 && rbenv exec bundle exec rake test) [10:31:30] _joe_: I'll try, thanks! [10:36:17] _joe_: that still complains with the same error "Error: Unknown Ruby version 2.5 found in `.ruby-version`." [10:36:53] * dcaro removed .ruby-version ... seems untracked by git :/ [10:38:22] and that was it xd, rubocop now worked, updating also my git hook to use that [12:18:07] fyi all i have just added a new function to puppet `wmflib::dir::mkdir_p` which does the equivilant of `mkdir -p` https://github.com/wikimedia/puppet/blob/production/modules/wmflib/functions/dir/mkdir_p.pp [12:23:27] jbond42: thanks! I think we've multiple places where that could be useful to reduce a lot the code to created nested directories [12:27:38] volans: np and hopefully :) [12:27:50] I've always wondered why it was not standard in Puppet? [12:29:06] jbond42, that looks super-useful, thank you [12:29:34] XioNoX: yes same for me, ill try to upstream this (or more likley https://github.com/voxpupuli/puppet-extlib/pull/176) to stdlib at some point [12:29:50] nice! [12:29:56] strange question, but do you know if it can be called multiple times on the same dir? [12:31:22] jynus: i because it uses realise i think it can hwever im not sure if the File[] {} syntax alters that behaviour [12:32:01] don't worry, I may test it myself [12:32:31] please let me knof if you do my intention is that it shuld be safe [12:53:43] (for context, I normally try to avoid this issue, but many times I realize a parent dir is necessary by more than 1 resource) [12:54:46] e.g. /srv/backups/snapshots is needed by snapshot puppet and /srv/backup/dumps is needed by dump puppet, so who creates /srv/backups? [12:55:17] sukhe: good to merge `dnsrecusor: update variable name for installing version from component (ea58d5a8b9)` ? [12:55:42] arturo: yes please! [12:55:46] ok! [12:55:55] thanks :-) [12:56:29] jynus: in this case im pretty confident yuo can have both wmflib::dir::mkdir_p('/srv/backups/snapshots') and wmflib::dir::mkdir_p('/srv/backup/dumps') and it will work [12:56:37] cool! [12:56:43] im just not sure what happens if yu have 2x wmflib::dir::mkdir_p('/srv/backups/snapshots') [12:56:51] gotcha [12:57:58] jynus: it clarify if wmflib::dir::mkdir_p('/srv/backups/snapshots') and wmflib::dir::mkdir_p('/srv/backup/dumps') dosen't work then this is a bug this is mostly an issue im trying to fix [12:58:59] I will test when I can and provide feedback if I found any issues [12:59:18] puppet (or ruby's usage) is not really that user friendly in the first place :-) [12:59:30] jbond42: thanks! I will admit when I was new to Puppet, I was surprised it couldn't do mkdir -p :) [14:40:59] jbond42: quick puppet question (or whomever knows xd), I don't see any tests on any profile modules, is there a rule against it or can I add some? [14:43:31] dcaro: yu mean spec test? there are a few in modules/profile/spec/classes [14:44:01] jbond42:yep, just saw it xd, I was expecting them to be under modules/profile//spec for some reason [14:44:08] 👍 [15:01:55] dcaro: i have an e.g. CR here: https://gerrit.wikimedia.org/r/c/operations/puppet/+/642423/ which shows som simplified examples for testing roles/profiles [15:02:45] specificly notice the line `let(:node_params) {{ '_role' => 'pki' }}` which makes CI look for hiera based on the node being in the pki role [15:03:06] awesome [15:06:04] is there a way to run jsut one profile tests? global:spec runs everything every time [15:06:46] and spec:profile runs all the profiles [15:07:11] dcaro: from withing the profile spec you can run `bundle exec rake spec SPEC=spec/classes/profile_pki_server.rb` [15:07:24] 👍 [15:07:30] dcaro: from withing the profile dir i.e. modules/profile you can run `bundle exec rake spec SPEC=spec/classes/profile_pki_server.rb` [15:11:35] fyi i have just merged a cosmetic update to ./utils/pcc (https://gerrit.wikimedia.org/r/c/operations/puppet/+/651911) ping me iof you see any issues [15:14:16] okok [16:17:11] FYI, the decom cookbook will now call homer automatically in the process, please let me know if you're having any issue decommissioning a host [17:46:34] so I was trying to figure out some grafana data oddness yesterday, and today it dawns on me that it's probably systemic... [17:47:27] the start of this mystery is looking at this, which is a req-rate graph for authdns1001 for the past hour, using "eqiad prometheus/global" as the data source: [17:47:32] https://grafana.wikimedia.org/d/Jj8MztfZz/authoritative-dns?viewPanel=2&orgId=1&from=now-1h&to=now&var-datasource=eqiad%20prometheus%2Fglobal&var-server=authdns1001 [17:47:43] those weird spiky dropouts are artificial, it's not really happening [17:47:58] if you switch the source to "eqiad prometheus/ops", they go away [17:48:22] the same seems to be true also for dns1001 and dns1002 graphs, switching between eqiad's ops and global sources [17:48:48] authdns1001 data also has the spiky dropouts if I look at the *codfw* prometheus/global dataset [17:49:29] but authdns2001 (which lives in codfw) is smooth in both codfw global and codfw ops datasets [17:50:11] just narrowing the problem naively by using the dropdowns, the dropouts seem to only affect data going from source "eqiad prometheus/ops" to both of "(eqiad|codfw) prometheus/global" [17:50:29] (there's also no spikes in e.g. esams or eqsin data in either global set) [17:52:22] (also not exhibiting the problem is authdns2001 in eqiad global data) [17:52:44] I'm not really sure if some cause is known or expected here, but it seems strange and confused me for a day or so [18:59:20] razzi: FYI on the cookbooks repo (and in general all sre-tool/automation repos) you just need to +2 a patch, CI will run and perform the auto-submit on success for you. [18:59:51] volans: cool, good to know [19:00:18] just a pro-tip ;) [19:00:45] Thanks for your reviews on the sre.druid.reboot-workers cookbook volans and elukey :) trying it now with --dry-run [19:01:11] great! thank you for writing it and bearing with me on all the nitpicks ;)