[08:33:53] <Samwalton>	 Is anyone online who might be able to check a toolsadmin membership request? At a hackathon and would super appreciate getting access for someone before the end of the day!
[08:34:45] <Reedy>	 I can probably do it...
[08:34:46] <Reedy>	 I think
[08:34:49] <Reedy>	 And he left
[08:35:38] <Samwalton>	 Think that was my old connection, wifi is a bit spotty. One sec :)
[08:37:28] <Reedy>	 names are hard :P
[08:38:56] <Samwalton>	 :D The request should be in; seanwiseman7
[08:39:44] <Samwalton>	 Actually I'm not seeing it in membership requests, have I forgotten how toolforge works?
[08:40:27] <Samwalton>	 Oh he didn't request membership yet
[08:40:37] <Samwalton>	 Ok now it's submitted :D
[08:41:19] <Reedy>	 I'm trying to remember where these are
[08:43:20] <Reedy>	 Samwalton: I've approved it..
[08:44:31] <Reedy>	 Samwalton: looks like it should be done
[08:44:51] <Samwalton>	 Thank you!
[09:24:24] <arturo>	 hey, I'm around in case you need me :-P
[09:33:39] <samwalton>	 arturo, (or anyone else with an answer), we'd like to use Docker on Toolforge, but appear to be missing docker-compose. Is there any documentation on how we can use docker?
[09:35:04] <arturo>	 samwalton: you would like to bring your own containers?
[09:35:33] <arturo>	 if that's the case, we don't support that... yet :-P
[09:36:05] <samwalton>	 We've got the docker-compose file to create the container
[09:36:40] <arturo>	 samwalton: some docs: https://wikitech.wikimedia.org/wiki/Portal:Toolforge/Admin/Kubernetes#Docker_Images
[09:41:29] <samwalton>	 Thanks!
[13:59:54] <andrewbogott>	 !log tools depooling a bunch of things before rebooting labvirt1001 for T194258:  tools-exec-1401 tools-exec-1407 tools-exec-1408 tools-exec-1430 tools-exec-1431 tools-exec-1432 tools-exec-1435 tools-exec-1438 tools-exec-1439 tools-exec-1441 tools-webgrid-lighttpd-1402 tools-webgrid-lighttpd-1407
[13:59:56] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL
[14:09:39] <chasemp>	 andrewbogott: godspeed, I have an apt at 10 fyi
[14:34:09] <andrewbogott>	 !log tools repooling labvirt1001 tools instances
[14:34:11] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL
[14:37:11] <halfak>	 !log wikilabels staged wikilabels-wmflabs-deploy:d382f3f
[14:37:12] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikilabels/SAL
[14:38:50] <halfak>	 !log wikilabels staged wikilabels-wmflabs-deploy:39da6a1
[14:38:50] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikilabels/SAL
[14:40:26] <halfak>	 !log wikilabels deployed wikilabels-wmflabs-deploy:39da6a1
[14:40:27] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikilabels/SAL
[16:25:08] <andrewbogott>	 !log services deleting instances pdfservice,  swproxy, zotero-test citoif-test citoid-jessie-test and sca1 as per T194276
[16:25:10] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Services/SAL
[16:25:10] <stashbot>	 T194276: Review all VMs in the 'services' WMCS project - https://phabricator.wikimedia.org/T194276
[19:42:34] <valhallasw`cloud>	 What's the distinction between 'profile' and 'role' in the puppet repo? modules/profile/files/labs/db/views/maintain-meta_p.py  vs  modules/role/files/labs/db/maintain-dbusers.py  feels a bit inconsistent
[19:43:09] <bd808>	 valhallasw`cloud: its a transition thing. Let me find the perfect world explanation on wikitech
[19:43:16] <valhallasw`cloud>	 :D
[19:43:35] <bd808>	 https://wikitech.wikimedia.org/wiki/Puppet_coding#Organization
[19:44:40] <bd808>	 in the perfect world version: profiles configure a useful service, and roles aggregate profiles such that each physical/virtual machine has a single role applied to it (e.g. MediaWiki content server)
[19:45:46] <bd808>	 But we used to apply 1-N roles to a server and a large number or roles have not be refactored into profiles yet
[19:46:41] <valhallasw`cloud>	 *nod*
[19:46:54] <bd808>	 valhallasw`cloud: for that specific example, half migrated based on recent updates I think
[19:47:39] <bd808>	 also we just like to make it hard to find and update code for fun
[19:47:44] <valhallasw`cloud>	 ;-)
[19:47:46] <bd808>	 its like a hide and seek game
[19:48:20] <valhallasw`cloud>	 Ok, so role::labs::db::replica should include 1...N profile::labs::db profiles, among which profile::labs::db::views which sets up the replica views
[19:48:38] <bd808>	 that sounds right, yes
[19:48:58] <bd808>	 modulo "labs" which I think we are going to start changing to "wmcs"
[19:49:24] <bd808>	 because change!
[19:50:12] <valhallasw`cloud>	 nothing that a little bit of shift-shift or ctrl-shifrt-F doesn't solve
[19:50:18] <bd808>	 so someday we should have role::wmcs::db::replica and that would include all the profiles or just plain modules that make a Wiki Replica server do its job
[19:51:22] <valhallasw`cloud>	 Right, that makes sense
[19:52:10] <valhallasw`cloud>	 Other question -- I'm planning to write a few tests for maintain-meta_p.py, but there isn't really a clear place to put those. I suppose the scripts really shouldn't live in ops/puppet to begin with, but moving things out also would cause a bunch of headaches
[19:52:46] <valhallasw`cloud>	 my current idea is to just add tests + test support files in a subdirectory, so that they can be run manually (although maybe not automatically)
[19:53:05] <valhallasw`cloud>	 it's also a bit of a mess with python2/python3 scripts mixed :/
[19:53:25] <bd808>	 hmm... bstorm_ was making some script python testable, but I don't know if she found a good place to put the tests
[19:53:55] <bstorm_>	 I gave up on that one because of how it is stored in puppet
[19:54:05] <bd808>	 "soon" it should be easier to kill off the py2 stuff. I think that the debian repo has py3 openstack client packages
[19:54:40] <valhallasw`cloud>	 in this case it only does some db stuff, so it should be OK to migrate it
[19:54:51] <bd808>	 valhallasw`cloud: in theory you could make pydoc tests and then do some magic check to run them I guess
[19:54:51] <valhallasw`cloud>	 but it also has no tests, which makes me not want to touch it without first writing tests :-p
[19:55:05] <valhallasw`cloud>	 mmm, interesting idea
[19:55:24] <bd808>	 like sniff for --test in __main__
[19:55:49] <valhallasw`cloud>	 yeah, or just make py.test figure it out
[19:56:46] <bd808>	 It would be nice to move most of our scripts out of the puppet repo, but I call not it on being the one to invent a bunch of new debs to deploy them
[19:57:03] <bstorm_>	 I haven't messed with that one much, but the first thing I tried to do was encapsulate what is in the other two scripts for the views in at least functions so that they could theoretically be tested in the future.  That's also why the index script uses underscores (any python test will typically complain with dashes in names).
[19:57:12] <bstorm_>	 debs or eggs?
[19:57:46] <bd808>	 the 3 blessed ways to deploy things are: puppet, debs, and scap3 repos
[19:57:52] <bstorm_>	 ahh
[19:58:45] <bd808>	 puppet is easy, but messy and in need of root +2. Debs are .. well, debs and not fun in my personal opinion. scap3 is pretty well suited for deploying a web app, but a little goofy for anything else
[19:59:32] <valhallasw`cloud>	 how's the infra for building debs these days? I remember I messed around with pbuilder and friends back in the day, but that was before we had the magic of docker
[19:59:59] <bd808>	 we have a cowbuilder server in the tools project that is not too horrible to use
[20:00:11] <valhallasw`cloud>	 (I assume the whole versioning is still a bit of a pain, with a million files to edit)
[20:00:25] <bd808>	 we really could use a small script to make publishing the debs to the apt repo easier
[20:00:52] <bd808>	 or a trusted jenkins server where we could just push a button :)
[20:01:24] <bd808>	 hmm... I wonder if our friends in releng have that trusted jenkins box these days...
[20:01:32] <mutante>	 you can let puppet deploy with git::clone from a repo where the repo doesn't need +2 from root
[20:01:39] <mutante>	 as method 3a
[20:01:55] <mutante>	 so then you just need that merged once but not for every script change in the future
[20:02:30] <mutante>	 that's something we do for content of static HTML sites 
[20:02:58] <bd808>	 scap3 is nicer than the puppet git clone I think. Only a bit more setup and lot more flexibility
[20:03:08] <bd808>	 but of course opinions vary
[20:04:31] <bd808>	 I have a situation right now where I'm building something as a tool, but part of it will eventually need to be deployed outside of the toolforge space. I'm considering copying the needed files into Puppet but that also makes me feel dirty
[20:05:25] <bd808>	 also, thanks for being nerd sniped into looking at that script valhallasw`cloud :)
[20:05:33] <valhallasw`cloud>	 *grin*
[20:05:41] <bd808>	 Its been on my list of things for *way* too long
[21:38:26] <valhallasw`cloud>	 bd808: https://gerrit.wikimedia.org/r/#/c/432698/ . That doesn't do anything yet, except for stop me from breaking anything :-p
[21:39:44] <valhallasw`cloud>	 Anyway, enough coding for today, I'm off to bed. G'nite all!
[21:41:13] <valhallasw`cloud>	 21:38:27 modules/profile/files/labs/db/views/test/test-maintain-meta_p.py:45:101: E501 line too long (530 > 100 characters)
[21:41:38] <valhallasw`cloud>	 ok, maybe I can find a better way to store the expected queries than a big text block in a python file :-p