[16:05:29] effie: I can't find it now, but you mentioned something about sockets for mcrouter [16:05:32] see https://phabricator.wikimedia.org/T235216 [16:05:51] could merge or track there if that's still on the roadmap :) [16:07:47] Krinkle: oh I have a patch uploaded for onhost memcached to listen to a unix socket [16:08:14] I have read T235216 at some point, but it is not something anyone is working on [16:08:14] T235216: Reconsider memcached connection method for MW in PHP7 world - https://phabricator.wikimedia.org/T235216 [16:09:21] Krinkle: what I can tell you though is that, if everything goes as planned, we will be able to get rid of the mcrouter proxies [16:10:06] https://phabricator.wikimedia.org/T271967 [16:11:43] now if we get to the point where mcrouter proxies are not needed, we can rethink mcrouter listening to a unix socket [16:12:08] does that information help? [16:12:47] hm.. I don't see the connection (no pun intended) between those two ideas. but it's not urgent, so doing that first is fine indeed. [16:13:11] I meant for mcrouter to have a socket for MW to use instaed of the localhost port we use today [16:13:46] there's only one address we use for all MW-mcr transmissions, right? to onhost tier, and gutter/main, and proxies etc is all after it gets to mcr afaik [16:20:56] Krinkle: I am not sure if mcrouter can listen to both a unix socket and a tcp socket, I will have to look it up [16:21:53] but regardless, priority-wise, let's take it one step at a time [16:22:00] ack [16:22:04] tx tx [16:22:42] ah it needs the tcp port for receiving purges from proxies. [16:22:48] ok, I missed that [16:23:58] I have not checked if that is still the case in 0.41 [16:24:33] this is becase we use a subset if "regular" appserver/mcrouter instances as our proxies is that right? [16:24:58] yeah, listening on both is not what I had in mind. I thought we could just swithc to sockets only but I forgot about the mcrouter-to-mcrouter part [16:25:30] that won't be an isuse indeed anymore once we talk to codfw memcs directly for broadcast [16:25:44] makes sense now :) [16:29:00] great :) [16:35:06] jbond42_: I could u se some guidance with puppet CI. I added a new module with a custom fact and jenkins is choking on it. [16:35:07] https://integration.wikimedia.org/ci/job/operations-puppet-tests-buster-docker/21606/console [16:35:19] I assume I need to add some mock or something to a spec someplace? [16:36:41] 23:18:12 rejected: parameter 'enumerable' expects an Iterable value, got Undef (file: /srv/workspace/puppet/modules/cinderutils/manifests/ensure.pp, line: 47, column: 54) (file: /srv/workspace/puppet/modules/profile/manifests/ci/slave/labs/common.pp, line: 9) on node 4141c7434a1a.integration.eqiad1.wikimedia.cloud [16:37:03] I suspect you need to add some defs to the mock hiera used in CI [16:38:10] cdanis: the data it's choking on come from facter rather than hiera [16:38:18] I imagine there's a mock for that someplace too? [16:39:40] https://phabricator.wikimedia.org/source/operations-puppet/browse/production/rake_modules/spec_helper.rb [16:40:43] and https://phabricator.wikimedia.org/source/operations-puppet/browse/production/rake_modules/default_facts.yml [16:41:33] thank you! [17:01:28] _joe_: now that https://gerrit.wikimedia.org/r/c/operations/puppet/+/668701 has been verified to be working on the beta cluster, can we merge it to remove the cherry pick at some point? [17:02:16] <_joe_> Majavah: jbond42_ has set up the PKI properly there, so I'd like to try to go that way instead, when I have a moment [17:27:57] cdanis: that helped! I don't suppose you can tell me why it's failing now? https://integration.wikimedia.org/ci/job/operations-puppet-tests-buster-docker/21666/console [17:29:30] cdanis: nm found it [17:29:56] correction: I found it [17:30:45] :D [17:32:06] what was it? [17:32:44] jenkins log has Could not parse for environment *root*: Illegal class reference (file: /srv/workspace/puppet/modules/profile/manifests/ci/dockervolume.pp, line: 15, column: 21) [17:34:02] seems weird that it goes on to run 1000 more tests after that [18:29:34] andrewbogott: it runs stuff in parallel so the log gets all mixed up [18:37:29] Oh, sure [19:13:53] I've just deployed a restbase change that should cut down on the spurious 429 errors [20:15:31] jbond42_: oh wow, I didn't expect you to pull the entire list into hiera! :) I had just been thinking have the upstream file in a template and then append a section where we add in service port numbers from https://wikitech.wikimedia.org/wiki/Service_ports (with those in hiera) [20:15:41] not that I *mind* this approach, it just wasn't what I had expected lol [20:18:00] cdanis: the use case that Xio.NoX has for homer i think makes it easier to include the whole list. and the other PS had simlar issues as we importe the entire services file so i thought its probably a fine pay of and it will make possible functions like netbase::resolve_port('kafka') etc much more usefull [20:18:13] yeah I like it :) [20:18:14] also i created a small rake task to update the file so maintance should be minimul [20:18:19] :) cool [20:18:20] very cool [20:19:08] thanks fyi oing to shut down for now, however if yu have a chance to think about the comment on https://gerrit.wikimedia.org/r/c/operations/puppet/+/670918/5/modules/profile/manifests/base/netbase.pp i can pick this up tomorrow [20:19:24] ok! will take a deeper look! [20:19:27] have a nice evening :) [20:19:32] thanks :0 [20:19:35] :) [20:30:10] jbond42: joke on you, I have Xio.NoX as highlight [20:32:09] XioNoX: lol well then see: https://gerrit.wikimedia.org/r/c/operations/puppet/+/670917/7 :P [20:32:36] yep, tomorrow [20:32:51] :)