[11:08:55] effie: https://logstash.wikimedia.org/goto/eef09dc50e0ca9338859e31e94ecae64 [11:09:02] undefined class, previously assumed to be an opcache bug [11:09:10] affects a single server, and has for the past 10 hours. [11:09:26] that's gotta be a new record if indeed opcache related, since usually they don't last that long. [11:09:35] parse2007 [11:09:51] I'm about to restart it, but can wait a few min in case there's something you'd like to look at or capture [11:10:03] yes I would like to look at something [11:12:14] apparently I can't ssh into this one, thats weird. [11:13:11] I guess it doesn't inherit any appserver-ish admin_groups [11:14:01] (e.g. neither 'deployment' nor 'perf-roots' is set, /me files task) [11:15:33] it is very different than other corruptions we had [11:16:51] I obviously cant say it is not opcache corruption [11:16:56] but I can't say it is either [11:16:58] :D [11:17:21] we never had opcache corruptions in parsoid, to my knowledge [11:17:28] ok, I will restart php-fpm [11:17:38] and let me know if you see this again or something similar [11:18:02] alright ? [11:18:59] It isn't in "parsoid" per se, it's in wmf-config/mwcore code seems equally likely to hid parsoid servers I think nowdays given the code and setup they have nowadays. [11:19:13] Yep, will do. [14:11:59] XioNoX: i see your update on the jjuniper quote, so close yet so far... [14:56:43] heh, looks like docker for mac will be paid soon - time for the unexpected comeback of vagrant VMs :D [14:58:03] great, amazing business plan [14:59:07] https://www.docker.com/blog/updating-product-subscriptions/ [15:03:25] hi all, trying to update the policies around access request. specificaly around things like NDA vs WMF; who approves users access and who approves new groups. in order to kick this of im trying to collect all the places where we mention access request processes so we can ensure they all agree and reduce repitition. as such i have created a etherpad page to collect links to any wiki's phab forms [15:03:31] that mention the process around access requests. ... [15:03:33] ... could i ask you all to please add anything i have missed, thanks [15:03:36] https://etherpad.wikimedia.org/p/access_request_wikis [15:04:05] (cc jynus: mutante: i think you have hit this issue recently so your insight would be good) [15:07:17] jbond: maybe L2 too? [15:07:45] the so-called Volunteer NDA which I'm not sure you're using - I think WMF uses/used Cobblestone to handle those? [15:10:02] hauskatze: thanks have added [15:10:19] It always confused me... having to sign in two places [15:11:11] L2 seems superfluous to me IFF you have to sign a volunteer NDA with WMF Legal too; [15:14:32] hauskatze: tbh i have not come accross l2 before L3 is what we normally ask for shell access. ANAL but i think they main difference is NDA says i wont disclouse anything L3 says i wont break anything [15:15:05] Oh, dupes, nice [15:15:14] L2 is mentioned in Wikitech, not sure if L3 too [15:15:49] hauskatze: do you have any links? [15:16:01] one sec please [15:16:04] thanks [15:16:29] https://wikitech.wikimedia.org/wiki/Volunteer_NDA [15:16:36] section: Privileged Phabricator access [15:16:53] "The rest of our contributors must sign a specific Trusted Volunteer Access & Confidentiality Agreement." [15:17:02] https://phabricator.wikimedia.org/L2 [15:19:58] ack thanks, have added that as well, seems like L2 is more about https://phabricator.wikimedia.org/tag/wmf-nda/ then shell access but the textis confusing (i.e. it mentions sysadmin access) [15:22:18] L3 is mentioned at https://wikitech.wikimedia.org/wiki/Production_access [15:24:04] L2 used to be used but then Legal switched volunteer NDAs to different system outside phab [15:24:21] and now it's probably not used consistently anymore [15:24:24] cobblestone in my time [15:24:52] I remember someone in -operations ranting about that system [15:25:43] ahh thanks mutante, zabe cheers already added that link [15:28:16] jbond, those 3 places are the ones I have seen [15:28:37] also the phab project and a README on puppet [15:28:53] although the README was more practical than policy [15:29:53] jbond: https://office.wikimedia.org/wiki/Guide_for_new_engineering_staff#Wikimedia_Developer_account [15:30:31] +1 to remove redundancy and link, BTW [15:31:33] great thanks, jynus was the phab project you mentioned shis one https://phabricator.wikimedia.org/project/view/1564/ [15:32:07] jbond: https://phabricator.wikimedia.org/T289552 [15:32:09] yep, I saw it ther, but addther the other [15:32:11] never mind i see you added 956 thanks [15:32:29] one last thing, it is offtopic but I wanted to fix too [15:32:52] contractors are mentioened on one of the 2 SRE vs LDAP [15:33:12] as in, expiration time, we should merge into 1, as expiration affects on puppet to both [15:33:38] mutante: plan to address T289552 [15:33:43] as we refresh the docs [15:33:43] but can be done later (updating description and templates for new ticket creation) [15:33:55] not sure if I got understood [15:34:15] The "Contract end date/Contract contact" [15:34:30] jynus: no im not sure i follow. we have that in data.yaml im not sure about the secodn location [15:34:47] yes, but it is refered on https://phabricator.wikimedia.org/project/view/1564/ [15:35:10] but not on https://phabricator.wikimedia.org/maniphest/task/edit/form/8/ [15:35:20] on manual or project description [15:35:24] ahh i see yes will do [15:35:29] minor thing [15:35:34] but if you are going to refactor the docs [15:35:40] better work once :-) [15:35:53] jbond: yep, it can be done later. thanks for this cleanup effort! [15:36:07] let me know how I can help [15:36:52] have added it thanks for the offer to help, if nothing elses reviewer wil be helpfull ) [15:37:06] please send them this way :-) [15:37:20] thanks <3 [15:37:23] although I may be done soon for today [15:37:40] it wont be today i dont think [15:37:46] I saw there was some inconsistency, but I really didn't felt capacitated to fix it [15:38:06] and as you said, contractor is a missused word [15:38:14] or overloaded one [15:38:19] the is inconsistency but also some stuff that changed recently which is just not documented so a refresh should be good :) [15:40:50] it would be good if there was a way to "add person in legal who handles NDAs" to phabricator tickets without having to know the name [15:41:00] or when legal assigns it to someone else [15:41:03] I am also a fan of creating more fine-grained groups, and I wouldn't mind having to maintain them [15:41:05] or vacations [15:43:30] ack and ack :) [15:45:03] unrelated but if you are tired of parsing ops-maint messages manually into google calendar invites, please LMK what you think on https://gerrit.wikimedia.org/r/c/operations/software/+/715980/ [15:49:17] godog: that looks amazing [15:51:49] legoktm: hehe thank you! [15:52:04] my javascript is goofy but it works [15:53:03] I would say I can't wait to try it, but actually I'm fine waiting :p [15:54:52] haha fair, we'll pass the torch to the next person on duty [15:55:14] jbond: a thought ..could be nice if we had a way to opt-out a set of hosts from the "always" groups [16:00:11] mutante: what use case? seems like we always want ops users. also having the absent group is also needed to remove old users [16:02:47] jbond: stuff like wikidough where we want people to trust we are not reading logs [16:03:10] but if it breaks we need to login and fix it [16:03:34] yea, but not all of the new sre-admin non-root users in addition? [16:04:06] dunno, maybe it is more for looks how many people get to ssh to it [16:04:32] the new user has no sudo roots and is not in adm so shouldn;t be able to read anything sensetive [16:04:47] *nod* ack [16:48:26] godog: I'm technically off today but I could give that JS a little touch up [17:07:12] Krinkle: thank you! that would great, feel free to update the review [20:35:36] Hello, could I trouble someone to merge https://gerrit.wikimedia.org/r/c/operations/puppet/+/715723 for me please? [20:59:41] thanks legoktm ! [21:02:11] {{done}} and np :)