[10:41:58] i'd like to test some puppet changes i'm making before sending them for review. https://wikitech.wikimedia.org/wiki/Puppet_coding#Cloud_VPS_testing implies i should request a cloud vps for doing this. but that seems somewhat involved. is there an existing vps instance available for this, or some other approach? [10:43:24] not technically testing, but are you aware of puppet compiler setup? [10:43:33] i am not [10:44:02] login here: https://integration.wikimedia.org/ci/login?from=%2Fci%2Fjob%2Foperations-puppet-catalog-compiler%2F [10:44:47] done [10:44:59] then go to https://integration.wikimedia.org/ci/job/operations-puppet-catalog-compiler/build?delay=0sec and list the patch number and list of nodes the puppet change will affect/test will not affect [10:45:28] ah, so i have to already have a gerrit change open, ok [10:46:16] this should run on CI, but it cannot run on all nodes and there is not a straightforward way to identify nodes that will be affected [10:46:26] note this is not technically testis as much as sanity checking [10:47:07] depending on the change, let us know and we can figure out a testing strategy [10:47:51] I recommend you to use it for any non-trivial change anyway [10:48:03] ok, i'll try it out [10:48:20] Alternatively you can write the list of nodes in the commit message such as `Hosts:mgmt1001.eqiad.wmnet`and run `check experimental` -> https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/545889/ [10:48:44] but if you can log in to the integration page I guess that's quicker [10:48:50] <_joe_> kormat: yes, sadly the puppet compiler has never been adapted to run on your local machine [10:49:19] well, it makes sense- fact loading, etc., it is complicated [10:49:20] <_joe_> kormat: also, ./utils/pcc is your friend for interacting with the compiler :) [10:49:42] <_joe_> jynus: it needs some engineering time, and a decent docker-compose based setup could be created [10:50:01] <_joe_> it's just no one dedicated a month or so to this [10:50:01] yep, what I said "it is complicated" [10:50:12] what does the output of this look like? i can't find a build that shows changes [10:50:40] https://puppet-compiler.wmflabs.org/compiler1002/23190/ [10:50:46] <_joe_> kormat: https://puppet-compiler.wmflabs.org/compiler1002/22613/ [10:50:47] last one run by luca [10:51:23] cheers [10:52:48] ಠ_ಠ `! [remote rejected] HEAD -> refs/drafts/production/repl_lag (draft workflow is disabled)` [10:55:28] Draft patches are disabled on our Gerrit install I think [11:01:50] <_joe_> yes kormat [11:01:55] <_joe_> a recent change [11:02:04] <_joe_> now you can post wip patches but not drafts [12:15:57] huh. what does this tool consider to be a "change"? https://integration.wikimedia.org/ci/job/operations-puppet-catalog-compiler/23197/ says "No changes", but the puppet-compiler link shows that there are, indeed, changes [12:17:10] kormat: where are you seeing no change? [12:17:34] https://usercontent.irccloud-cdn.com/file/eqU4oemm/image.png [12:17:34] <_joe_> i guess on jenkins [12:17:43] there are still OOM kills happening on kubernetes nodes atm, is that known/expected? [12:17:44] oh on the build status page i never noticed that before [12:17:54] <_joe_> jenkins integration isn't great, you need to look at the console output [12:18:05] <_joe_> hnowlan: of what? sessionstore? [12:18:22] looks like changeprop in the one I just noticed [12:18:25] <_joe_> that a pod might get oom'd is not unexpected in a void [12:18:35] <_joe_> it might mean you need more memory for your pod [12:18:36] _joe_: ah, i see [12:18:55] <_joe_> kormat: yeah "pcc" will show you that console output [12:19:34] <_joe_> basically we wired the ability to spawn jobs from jenkins, but never cared to integrate the results with jenkins itself [12:19:42] hah, gotcha [12:19:50] <_joe_> if you want to write some groovy to improve it, be my guest :) [12:20:19] 😮 [12:20:54] <_joe_> hey I had to try :P [12:21:10] 🚫 [12:22:26] <_joe_> for historical context: the compiler was a tool I originally wrote quickly to support the puppet migration from 0.27 to 3.x [12:22:59] <_joe_> then it evolved into something generally useful and jenkins was the answer to "how do I allow everyone to run the compiler without having to ssh into the vms"? [12:26:01] right :) [15:20:49] arturo, Krenair: https://gerrit.wikimedia.org/r/c/operations/software/acme-chief/+/605237 and https://gerrit.wikimedia.org/r/c/operations/software/acme-chief/+/605254/ are the acme-chief side for T255249. I'll let them open till Monday/Tuesday to give you some time to check it. Basically they provide support for a .crt.key file that includes the .crt and the .key content :) [15:20:50] T255249: acme-chief: support for generating a concatenated cert/key file - https://phabricator.wikimedia.org/T255249 [15:21:15] IIRC no changes are required on the puppet acme_chief::cert resource [15:37:46] ack tthanks [16:36:33] Is the current best practice to put monitoring defines in the class or in the profile? [16:36:39] (probably a question for _joe_ ) [17:20:49] andrewbogott: I think profile as a monitoring define would be crossing module barriers? I haven't read the style guide for a while but I remember that as a criteria for module vs profile at some point [17:28:13] andrewbogott: according to this, it belongs in a profile::::monitoring class (https://wikitech.wikimedia.org/wiki/Puppet_coding#WMF_Design_conventions) [17:32:38] Hm... Ok I will reread all that [19:34:25] ah, shdubsh, that's for external monitoring which makes sense but in my case I was thinking about nrpe (which apparently goes in the main profile) [19:35:46] no complaints here :) [20:30:22] anyone around for a trivial +1 on https://gerrit.wikimedia.org/r/c/operations/puppet/+/605314 ?