[03:29:37] <wikibugs>	 10Traffic, 10Operations: certcentral: phantom test failure around challenge success - https://phabricator.wikimedia.org/T203422 (10Krenair) p:05Triage>03Normal
[03:41:11] <wikibugs>	 10Traffic, 10Operations: certcentral: Provide script for certificate revocation - https://phabricator.wikimedia.org/T203423 (10Krenair) p:05Triage>03Normal
[13:14:17] <wikibugs>	 10Traffic, 10Operations: certcentral: phantom test failure around challenge success - https://phabricator.wikimedia.org/T203422 (10Vgutierrez) I've been working under the assumption that basically our client was too aggressive and some times pebbles wasn't quick enough, but apparently it's getting stuck during...
[13:35:04] <wikibugs>	 10Traffic, 10Operations: certcentral: phantom test failure around challenge success - https://phabricator.wikimedia.org/T203422 (10Vgutierrez) Same happens with http-01 validation, but in this case pebble output is more helpful cause it's more verbose: ```expected pebble output during http-01 validation Pebble...
[13:56:26] <Krenair>	 vgutierrez, around?
[13:57:44] <vgutierrez>	 yip
[13:57:57] <vgutierrez>	 debugging the phantom tests issue
[14:01:47] <Krenair>	 vgutierrez, so tox will pull dependencies from setup.py tests_require?
[14:02:46] <vgutierrez>	 yup, by running python setup.py install or python setup.py tests
[14:03:09] <vgutierrez>	 BTW, replacing == with >= it's kinda tricky
[14:03:21] <vgutierrez>	 maybe we should run the tests twice
[14:03:42] <vgutierrez>	 once against the expected versions in stretch, and another one against *at least* the stretch versions
[14:06:16] <vgutierrez>	 hmmm I already know why our tests fail sometimes
[14:06:30] <vgutierrez>	 the fake dns server inside test_pebble.py is not resilient enough
[14:07:15] <vgutierrez>	 I'm pretty tempted to rewrite the DNS server with dnspython
[14:07:36] <vgutierrez>	 and drop that dnslib stuff
[14:12:01] <vgutierrez>	 .. sigh! never trust random code snippets
[14:12:15] <vgutierrez>	 running strip() on a bunch of bytes is a pretty bad idea :)
[14:13:21] <ema>	 :)
[14:13:41] <vgutierrez>	 volans: regarding testing against different versions of the deps
[14:13:55] <vgutierrez>	 volans: IIRC you do that somewhere, right?
[14:14:05] <volans>	 vgutierrez: yes, but I'm entering a meeting now
[14:14:21] <vgutierrez>	 volans: ttyl <3
[14:14:27] <volans>	 see https://github.com/wikimedia/cumin/blob/master/setup.py#L50
[14:14:31] <volans>	 and the related tox.ini
[14:15:02] <vgutierrez>	 thx
[14:15:12] <vgutierrez>	 Krenair: ^^ we can use that as an inspiration :)
[14:16:02] <volans>	 it's not perfect, you could argue that you should test all possible combinations
[14:16:51] <volans>	 the assumption is that all install deps are >= or ==, never free version
[14:18:15] <vgutierrez>	 free versions? we're not savages!
[14:18:16] <vgutierrez>	 ;P
[14:30:46] <wikibugs>	 10Traffic, 10Operations, 10Patch-For-Review: certcentral: phantom test failure around challenge success - https://phabricator.wikimedia.org/T203422 (10Vgutierrez) As mentioned in https://gerrit.wikimedia.org/r/457915, performing a string strip() operation on a bunch of bytes that are actually a DNS query it'...
[14:34:15] <bblack>	 lol @ "I'm pretty tempted to rewrite the DNS server" <- is probably always a bad idea in the general case, the rabbithole is infinite
[14:34:46] <bblack>	 although for a test harness piece, I'm sure it can be managed, the statement just stood out in general :)
[14:34:47] <vgutierrez>	 bblack: well... it's a tiny fake DNS server used in the integration tests
[14:35:11] <vgutierrez>	 for the real thing I let it you handle it ;P
[14:36:02] <bblack>	 exactly :P  If only someone had said that to me 10 years ago!
[14:38:06] <Krenair>	 bblack, was gdnsd supposed to be tiny?
[14:38:55] <bblack>	 I was a couple months into a new job, and we were contemplating buying some exorbitantly expensive F5 Global Load Balancers to do GeoDNS, and I said something like "I'm pretty tempted to rewrite the DNS server [in perl]"
[14:39:03] <bblack>	 and then I did, and then the rabbithole just kept going
[14:39:18] <Krenair>	 haha
[14:39:54] <vgutierrez>	 Krenair: BTW, it will be also pretty interesting to test our codebase against python 3.5-3.7, to see how it will behave after upgrading to buster
[14:40:08] <vgutierrez>	 but of course that could be included in another commit and not in this one
[14:40:23] <vgutierrez>	 https://github.com/wikimedia/cumin/blob/master/tox.ini <-- something like this
[14:40:40] <Krenair>	 I've been using python 3.5
[14:41:03] <vgutierrez>	 it also works in python 3.7 in OSX
[14:41:04] <vgutierrez>	 O:)
[14:41:05] <bblack>	 the very first version was a perl daemon, which only had the bare minimum bits to do GeoDNS for A-records, and you had to delegate a "zone" for e.g. www.example.com to the perl DNS server just for that one IP, because it couldn't do all the other general-case parts of the authserver
[14:42:41] <Krenair>	 looks like buster has 3.6
[14:42:46] <vgutierrez>	 yep
[14:43:02] <vgutierrez>	 so at least covering 3.5 and 3.6 will be useful IMHO
[14:46:18] <Krenair>	 vgutierrez, 
[14:46:22] <Krenair>	 14:45:05 ERROR: InvocationError: could not find executable 'pylint'
[14:46:25] <Krenair>	 14:45:10 ERROR: InvocationError: could not find executable 'coverage'
[14:47:32] <vgutierrez>	 right, you cannot ask for pylint or coverage without tellint tox that they should be installed before
[14:47:41] <vgutierrez>	 https://github.com/wikimedia/cumin/blob/master/tox.ini#L39-L43
[14:47:48] <vgutierrez>	 I think you're missing something like that :)
[14:49:05] <vgutierrez>	 and the proper adjustment in setup.py ofc
[14:49:37] <vgutierrez>	 (too late, seeing PS19)
[14:50:00] <Krenair>	 oh right
[14:51:57] <vgutierrez>	 Krenair: I'm wondering if I should do a rebase and inject the test fix before the packaging commit
[14:52:14] <Krenair>	 could do in a minute
[14:52:24] <vgutierrez>	 it would make our lifes easier merging the 3 other commits
[14:52:53] <wikibugs>	 10Traffic, 10Operations, 10TechCom-RFC, 10Patch-For-Review, and 3 others: Harmonise the identification of requests across our stack - https://phabricator.wikimedia.org/T201409 (10Ottomata) > But I'm unsure whether we should also standardise the value format of the header (as UUID).  I'd be fine with not re...
[14:57:14] <vgutierrez>	 Krenair: I'm already checking the error in PS20
[14:58:52] <vgutierrez>	 Krenair: right, the dependency name is not openssl, is pyOpenSSL
[15:00:16] <Krenair>	 and uh
[15:00:17] <Krenair>	 pyyaml
[15:00:54] <vgutierrez>	 :)
[15:02:43] <Krenair>	 need to move some stuff from tests_require into extras_require?
[15:03:00] <vgutierrez>	 yup
[15:03:25] <vgutierrez>	 requests_mock and dnslib are test deps
[15:05:08] <Krenair>	 hmm
[15:05:19] <Krenair>	 wrong version of acme?
[15:05:59] <vgutierrez>	 let me check
[15:07:03] <vgutierrez>	 yeah.. too newer I'm afraid
[15:07:06] <vgutierrez>	 acme==0.26.1
[15:07:39] <vgutierrez>	 that's what I was saying that testing against >= and == are different things :)
[15:08:27] <Krenair>	 yeah
[15:09:06] <vgutierrez>	 of course it would be nice to be able to detect that kind of issue ASAP, so IMHO both tests are needed
[15:09:23] <vgutierrez>	 but of course I'd break the build only if it fails against debian versions
[15:13:00] <ema>	 bblack: ATS returns 404 to PURGE requests if the object is not cached
[15:13:14] <Krenair>	 15:11:28 ************* Module certcentral.certcentral_api
[15:13:14] <Krenair>	 15:11:28 I: 61, 0: Locally disabling unused-variable (W0612) (locally-disabled)
[15:13:14] <Krenair>	 15:11:28 E: 95,19: Method 'logger' has no 'info' member (no-member)
[15:13:14] <Krenair>	 15:11:28 E:115,23: Method 'logger' has no 'info' member (no-member)
[15:13:25] <ema>	 bblack: which is probably a feature, we can now tell precisely how many purges were useless
[15:13:41] <Krenair>	 flask change maybe?
[15:14:05] <Krenair>	 we say >= 0.12.1, it's got 1.0.2
[15:14:12] <vgutierrez>	 yup
[15:14:14] <vgutierrez>	 huge change
[15:14:42] <vgutierrez>	 could we set all the install deps as == for this commit?
[15:14:47] <ema>	 bblack: that being said, vhtcpd logs a message every time the purge returned status code > 400. We probably want to change that, maybe log a message if status code > 400 and != 404?
[15:15:00] <vgutierrez>	 so we get the same versions that we get in debian stretch packages
[15:15:12] <Krenair>	 looks like they went 0.12.1 through 0.12.4, then 1.0, 1.0.1, 1.0.2
[15:15:19] <volans>	 you can set >=0.12.1,<1.0.0
[15:15:20] <vgutierrez>	 and then we'll sort out a strategy to give compatibility against new versions
[15:15:21] <bblack>	 ema: yeah seems like the sane thing to do
[15:15:32] <vgutierrez>	 what volans suggests makes sense as well
[15:15:59] <volans>	 see https://github.com/wikimedia/debmonitor/blob/master/setup.py#L11  for example
[15:16:19] <ema>	 bblack: >= 400 that is. Thanks! :)
[15:16:44] <bblack>	 well, there's another subtlety in there
[15:17:04] <bblack>	 there's also this gem: pr->status_ok = p->status_code < 400;
[15:17:23] <bblack>	 oh it's all part of the same check, right
[15:17:43] <ema>	 yeah
[15:18:02] <bblack>	 yeah so just update that conditional to exclude 404 and change the warning output text, should be good! :)
[15:19:28] <Krenair>	 alright well tests are succeeding again finally
[15:19:39] <vgutierrez>	 nice :D
[15:20:07] <Krenair>	 the following are the ones without >=
[15:20:08] <Krenair>	         'pylint < 1.7.0',
[15:20:08] <Krenair>	         'acme == 0.25.1',
[15:20:08] <Krenair>	         'flask == 0.12.1',
[15:20:20] <vgutierrez>	 Krenair: btw, why are you limitting pylint?
[15:20:29] <Krenair>	 I don't remember
[15:20:38] <vgutierrez>	 also get rid of that empty line in setup.py:11 :)
[15:20:42] <volans>	 newer ones usually complain about more things, but is good :)
[15:21:29] <vgutierrez>	 Krenair: hmm do we need to have dup. dependencies between install_requires and extras_requires?
[15:21:45] <Krenair>	 I'm not sure
[15:21:51] <volans>	 no
[15:22:10] <volans>	 when you use .[foo] that installs install_requires + extras_requires[foo]
[15:22:34] <volans>	 I think I've put that in a comment in cumin's tox.ini IIRC
[15:22:48] <vgutierrez>	 nice, so lets get rid of the dups as well :D
[15:23:05] <vgutierrez>	 but overall this is looking pretty well \o/
[15:23:38] <Krenair>	 so I can drop the stuff from extra_requires that are in install_requires?
[15:23:59] <vgutierrez>	 indeed
[15:26:43] <Krenair>	 let's return to fixing pylint, acme, flask etc. for the future in another commit
[15:26:58] <Krenair>	 for now I'm trying volans' >=0.12.1,<1.0.0 etc.
[15:27:15] <Krenair>	 and acme >= 0.25.1, < 0.26.0
[15:27:26] <Krenair>	 (I assume it was 0.26.0 that broke things and not 0.26.1)
[15:28:35] <vgutierrez>	 ack
[15:29:01] <Krenair>	 (PS27 fail is the phantom test bug)
[15:29:07] <vgutierrez>	 yup
[15:30:23] <Krenair>	 third time lucky...
[15:36:34] <vgutierrez>	 hmm let's apply https://gerrit.wikimedia.org/r/#/c/operations/software/certcentral/+/457915/ ASAP :)
[15:37:16] <Krenair>	 yeah
[15:37:20] <Krenair>	 will do
[15:38:07] <vgutierrez>	 Krenair: BTW, it would be nice to include in the README.md the steps required to generate the .deb package itself
[15:40:22] <ema>	 bblack: something like this? https://gerrit.wikimedia.org/r/#/c/operations/software/varnish/vhtcpd/+/457927/
[15:40:49] <Krenair>	 vgutierrez, I'm beginning to loose track of all the things we've said we should do over IRC
[15:41:02] <Krenair>	 with all the things I haven't addressed from previous comments
[15:41:08] <vgutierrez>	 ack
[15:42:10] <ema>	 bblack: jenkins failing because it tries to run debian-glue stuff but this is the master branch, trying to figure out how to avoid that :)
[15:43:00] <Krenair>	 I've got
[15:43:09] <Krenair>	 * fix new versions of pylint/acme/flask dependencies
[15:43:21] <Krenair>	 * README for .deb creation
[15:43:28] <Krenair>	 * https://gerrit.wikimedia.org/r/#/c/operations/software/certcentral/+/456646/17/cli/make_account
[15:43:31] <Krenair>	 * https://gerrit.wikimedia.org/r/#/c/operations/software/certcentral/+/456646/17/debian/install
[15:43:52] <Krenair>	 * https://gerrit.wikimedia.org/r/#/c/operations/software/certcentral/+/456646/7/debian/source/format
[15:43:58] <Krenair>	 vgutierrez, does that list sound complete?
[15:44:24] <vgutierrez>	 https://gerrit.wikimedia.org/r/#/c/operations/software/certcentral/+/456646/17/debian/service from moritzm 
[15:44:35] <vgutierrez>	 also https://gerrit.wikimedia.org/r/#/c/operations/software/certcentral/+/456646/17/debian/postinst
[15:44:38] <Krenair>	 vgutierrez, thought I did that one?
[15:44:54] <Krenair>	 yeah look, that got done: https://gerrit.wikimedia.org/r/#/c/operations/software/certcentral/+/456646/27/debian/service
[15:45:07] <vgutierrez>	 right.. 28 change sets..
[15:45:07] <vgutierrez>	 :)
[15:45:15] <Krenair>	 as did your second one: https://gerrit.wikimedia.org/r/#/c/operations/software/certcentral/+/456646/27/debian/postinst
[15:45:40] <vgutierrez>	 hmmm
[15:45:49] <vgutierrez>	 if we're failing cause www-data doesn't exist
[15:46:04] <vgutierrez>	 it should be sane to require either nginx or apache as a dependency, right?
[15:47:04] <Krenair>	 other web servers might work
[15:47:15] <Krenair>	 I've written the nginx config for it but I imagine apache could do it
[15:48:17] <bblack>	 ema: yeah looks fine.  we never had a separate debian branch since it was only really for making a local deb.  maybe should, but whatever works easiest
[15:49:06] <vgutierrez>	 Krenair: I guess that any package providing "httpd"
[15:49:23] <vgutierrez>	 looks like both apache2 and nginx packages provide it
[15:53:01] <vgutierrez>	 Krenair: https://packages.debian.org/stretch/httpd
[15:53:21] <vgutierrez>	 Krenair: listing httpd as a dependency will require any of those installed, but not one in particular
[15:53:44] <Krenair>	 do we know if they all provide www-data?
[15:54:33] <wikibugs>	 10netops, 10Operations, 10ops-codfw, 10ops-eqiad: Audit switch ports/descriptions/enable - https://phabricator.wikimedia.org/T189519 (10ayounsi) 05Open>03Resolved Yep, all good! Thanks!  Alert created with this runbook: https://wikitech.wikimedia.org/wiki/Network_monitoring#Port_with_no_description_on_...
[16:00:39] <ema>	 bblack: we do have a debian branch actually :)
[16:01:45] <vgutierrez>	 Krenair: sadly nope :(
[16:01:53] <vgutierrez>	 Krenair: yaws doesn't do it for instance
[16:02:22] <wikibugs>	 10Traffic, 10Operations, 10Patch-For-Review: certcentral: phantom test failure around challenge success - https://phabricator.wikimedia.org/T203422 (10Krenair) 05Open>03Resolved
[16:02:25] <wikibugs>	 10Traffic, 10Operations, 10Goal, 10Patch-For-Review: Deploy a scalable service for ACME (LetsEncrypt) certificate management - https://phabricator.wikimedia.org/T199711 (10Krenair)
[16:02:37] <bblack>	 ema: oh hmm
[16:02:55] <bblack>	 ema: maybe jenkins shouldn't check master?
[16:03:54] <ema>	 bblack: it should only check the "debian" branch. Unfortunately you can call the debian branch whatever you want (master is a common choice)
[16:05:10] <ema>	 it's even gbp-buildpackage's default for --git-debian-branch
[16:05:27] <bblack>	 maybe it should skip if there's no debian/ subdir?
[16:06:03] <ema>	 yeah that seems like a good idea
[16:06:34] <vgutierrez>	 Krenair: let's keep it like that unless we find something better then
[16:07:05] <Krenair>	 vgutierrez, like it currently is?
[16:07:19] <Krenair>	 we could depend on http and do the www-data user check
[16:07:20] <vgutierrez>	 Krenair: yup, in PS28
[16:07:29] <Krenair>	 httpd*
[16:07:35] <vgutierrez>	 right
[16:07:46] <vgutierrez>	 we could echo a warning if it doesn't exists
[16:07:58] <vgutierrez>	 like.. fix the systemd unit file before running certcentral
[16:10:37] <vgutierrez>	 Krenair: BTW, run_backend looks like it should be a main() function in certcentral.certcentral
[16:10:55] <vgutierrez>	 and just list that main function as an console entry_point in setup.py
[16:11:09] <vgutierrez>	 (adding a comment..)
[16:13:42] <Krenair>	 vgutierrez, yeah you already did a comment about that
[16:13:44] <Krenair>	 haven't got to it yet
[16:13:54] <vgutierrez>	 ack
[16:13:58] <Krenair>	 next on the list though
[16:14:01] <vgutierrez>	 :D
[16:15:47] <ema>	 bblack: ok to release? tests are green on the debian branch https://gerrit.wikimedia.org/r/#/c/operations/software/varnish/vhtcpd/+/457934/
[16:16:42] <Krenair>	 vgutierrez, how about PS30?
[16:17:12] <Krenair>	 (I know I need to do the same thing on the new make_account commit)
[16:17:45] <ema>	 bblack: not urgent of course, just looking forward to seeing ATS dealing with all the purges :)
[16:18:05] <vgutierrez>	 Krenair: looking good :D
[16:20:25] <Krenair>	 apparently jenkins disagrees
[16:20:53] <Krenair>	 oh because I made a new function without a docstring
[16:22:39] <vgutierrez>	 Krenair: yup.. linters are crying
[16:24:59] <Krenair>	 okay so
[16:25:02] <Krenair>	 after dinner
[16:25:03] <Krenair>	 * fix new versions of pylint/acme/flask dependencies
[16:25:03] <Krenair>	 * README for .deb creation
[16:25:03] <Krenair>	 * https://gerrit.wikimedia.org/r/#/c/operations/software/certcentral/+/456646/7/debian/source/format
[16:25:15] <bblack>	 ema: yes!
[16:33:42] <Krenair>	 also:
[16:33:43] <Krenair>	 W: python3-certcentral: binary-without-manpage usr/bin/certcentral-backend
[16:33:43] <Krenair>	 W: python3-certcentral: binary-without-manpage usr/bin/certcentral-make-account
[16:37:12] <volans>	 just as a double check always do a dpkg -c of the generated deb to check if everything is there
[16:37:19] <volans>	 and if there aren't things supposed to be there ;)
[16:37:36] <volans>	 (in addition to lintian of course, but I see you're already doing that)
[17:05:28] <Krenair>	 volans, yeah I'm doing that
[17:05:32] <Krenair>	 alex@alex-laptop:~/Development/Wikimedia/Operations-Software-Certcentral (review/alex_monk/T203422)$ cat build.sh 
[17:05:35] <Krenair>	 gbp buildpackage --git-export-dir=../build-area/python3-certcentral -b --git-ignore-new
[17:05:37] <Krenair>	 dpkg -c ../build-area/python3-certcentral/python3-certcentral_0.1-1_all.deb
[17:57:41] <volans>	 bblack: are there any limit in place on the gdnsd side for the TTL of the discovery records?
[18:05:02] * volans afk, will read later
[18:23:59] <wikibugs>	 10netops, 10Operations: cr2-eqdfw (MX204) vhclient log noise - https://phabricator.wikimedia.org/T203261 (10ayounsi) a:03ayounsi Opened JTAC case 2018-0904-0650.
[19:36:19] <wikibugs>	 10netops, 10Operations: cr2-eqdfw (MX204) vhclient log noise - https://phabricator.wikimedia.org/T203261 (10ayounsi) Confirmed by JTAC, it's PR1315128.
[19:47:15] <bblack>	 volans: do you mean like a minimum floor value?
[19:49:14] <bblack>	 volans: the default gdnsd config has a "min_ttl" setting of 5s, and it will raise anything to at least that (even static records).  We can explicitly configure that down as low as 1, but not 0.
[19:51:03] <bblack>	 volans: and in the zonefile template (wmnet) they're configured with a TTL of 300/10 (max 300, min 10)
[19:51:23] <volans>	 bblack:  yeah that 300/10 I was looking for
[19:51:31] <volans>	 but didn't find at first look
[19:52:20] <bblack>	 the intent of the ranging there (max=300, min=10) is to let healthchecks vary the TTL within the range, but I'm not honestly sure what currently happens with that range and our lack of healthchecks, just manual admnistrative states...
[19:52:31] <bblack>	 well "manual" via confd I mean
[19:53:48] <bblack>	 but you can always skip that complexity and set a fixed value there with a slash
[19:53:55] <bblack>	 e.g. 5/5 for a fixed 5s TTL
[19:54:14] <volans>	 ok, but yeah that  answers completely my question, I was looking in the discovery config files and didn't thought of checking the zone file
[19:55:28] <bblack>	 the whole automagic TTL mangling was meant to be dropped in 3.x anyways, it's confusing and tries too hard to be smarter than it is
[19:55:37] <bblack>	 it may have to wait for 4.x though, to get killed!
[19:56:50] <volans>	 lol, so what's the plan you have in mind ?
[19:57:09] <bblack>	 volans: looking closer a bit myself, it looks like our confd stuff for discovery-dns has a TTL setting in confd too, the 300/10 just caps the range it can express (so does the global config's min_ttl=5)
[19:57:09] <volans>	 it's actually used for the switchdc, we lower the TTL before it and re-raise it after
[19:57:34] <volans>	 yes, that I was aware (the confd part)
[19:58:00] <bblack>	 I don't have a fully-formed plan for how to replace it, that's part of why it's probably not making 3.x
[19:58:13] <volans>	 lol, fair enough
[19:58:17] <bblack>	 but to be clear, I don't think being able to administratively tweak TTLs is a bad idea.
[19:58:34] <bblack>	 the Bad part of the current stuff is how the healthchecks automagically affect them, in cases where healthchecks are used
[19:58:46] <volans>	 got it
[20:00:03] <bblack>	 the gdnsd healthcheck plugins have anti-flap counters to smooth raw health results into stable states.  e.g. "Starting from perfect, it will take X isolated probe failures without an intervening run of Y sequential successes to trigger state transition to unhealthy", but a bit more complex than that.
[20:00:45] <bblack>	 so because of this, even though the true state of the resource is unpredictable, it can predict the minimum time it will take for a persistent failure to show through the anti-flap and be exposed as a state change.
[20:01:10] <bblack>	 so it would automatically gradually turn down TTLs based on this anticipated time-to-declared-failure.
[20:02:01] <bblack>	 which is kind of neat, but also really complicated and poorly understood, and probably not as useful as it seems at first :)
[20:05:07] <volans>	 right, it's ahead of it's time ;)
[20:07:04] <bblack>	 I may bring back something similar, but without it being TTLs.  Maybe have it adjust weights on a weighted pool of alternate answers (slowly drop the weight of a failing resource before removing it completely)
[20:07:08] <bblack>	 I donno
[20:07:33] <bblack>	 there's a lot of possibilities for feedback loops in either case though
[20:08:15] <bblack>	 (e.g. dynamic weight drop stabilizes a failing service, reaching some unintended intermediate state of barely-functional-but-kinda-failing)
[20:09:35] <bblack>	 but anyways, if that magic is killed, we wouldn't need these min/max TTL concepts on dynamic records.  there's no real reason to put range caps on something that can only be explicitly configured (e.g. by the mechanism confd uses, or the admin_state file)
[20:10:10] <volans>	 as of now it actually helps me to know there is a cap
[20:10:36] <bblack>	 how so?
[20:11:01] <volans>	 and in general might be useful to avoid mistakes, but you might argue that this check should be elesewhere, in the confd template or conftool itself
[20:11:09] <bblack>	 right
[20:11:26] <volans>	 it's just quicker, after lowering the TTL to say 10, we want to wait old_ttl before doing anything
[20:11:40] <bblack>	 ah I see
[20:11:42] <volans>	 and right know I know that waiting 300s cover all cases
[20:11:56] <volans>	 if it was open I should get max(TTL) from conftool
[20:11:59] <volans>	 not a big deal
[20:12:09] <bblack>	 yeah, we should probably have some rules in the etcd/confd part of it for capping it, I donno
[20:12:18] <volans>	 so don't let this corner use case drive any logic change
[20:12:36] <bblack>	 you could also make the argument that the zonefile TTL should still be honored as max, just no min-cap setting there
[20:13:08] <bblack>	 it seems like an un-useful case to support, using dynamic administrative input to raise a TTL larger than it's specified in the zonefile
[20:14:23] <bblack>	 anyways, 3.x already has a net reduction of ~3600 lines of code, in spite of being better-documented and enforcing a new code style that added at least a line per function :P
[20:14:29] <bblack>	 more complexity reduction can wait for 4.x!
[20:14:43] <volans>	 ahahah
[20:14:45] <volans>	 nice!
[20:15:11] <volans>	 I'm not sure there aren't useful cases in which you could legitimate ask to set a record TTL higher than the zone file
[20:15:14] <volans>	 's one
[20:15:44] <bblack>	 well there are definitely useful times to say "hey this TTL should be higher, let's change it", but that seems more like a persistent change you'd make to a zonefile.
[20:16:02] <bblack>	 temporary changes, seem like they would always be reductions against the default/max
[20:16:08] <bblack>	 (in operational practice, I mean)
[20:16:19] <volans>	 for example as the zone TTL is the default, you could for sake of DRYness and reduce verbosity avoid to repeat your low default everywhere
[20:16:30] <volans>	 but then having 5 records that you want with higher TTL, dunno, just rambling
[20:17:44] <bblack>	 you could still put explicitl TTLs on just those 5 in the zonefile
[20:18:18] <volans>	 and change them dynamically up tp that value?
[20:18:26] <bblack>	 someone should make a patch against ops/dns to remove all the pointless 'IN' on all the lines too heh
[20:18:29] <bblack>	 yeah
[20:18:47] <bblack>	 the 'IN' part of the RRs is optional and IN is the default
[20:18:59] <bblack>	 and also the only allowed value in gdnsd's case
[20:19:19] <volans>	 eheheh right
[20:19:41] <volans>	 if/when you do it tell me that I might have to update the zone validator script ;)
[20:19:45] <bblack>	 maybe wait for after the Great Netbox Transition, when much of our data becomes un-manual
[20:20:08] <volans>	 makes sense
[20:21:07] <bblack>	 251 files changed, 12999 insertions(+), 16606 deletions(-)
[20:21:20] <bblack>	 ^ current master..3.x net diff :)
[20:21:33] <volans>	 wow
[20:21:42] <bblack>	 I'm almost there, just trying to squeeze in a few last minute things
[20:21:44] <volans>	 quite some work!
[20:23:12] <bblack>	 I'm hoping/planning to push back to the main repo's master sometime Soon, and then cut some kind of alpha release we can try out here before trying to make a real 3.0 release
[20:23:21] <bblack>	 maybe later this week, if no annoying setbacks in QA stuff
[20:23:46] <bblack>	 (but I said that last week heh)
[20:24:40] <volans>	 ehehe
[21:25:04] <nuria>	 hola
[21:25:28] <nuria>	 wondering  if this wiki is frontend by varnish: fixcopyright.wikimedia.org/wiki/Main_Page
[21:27:08] <nuria>	 cc bblack 
[21:27:15] <bblack>	 nuria: it is
[21:27:20] <nuria>	 bblack: k
[21:27:41] <bblack>	 nuria: need something patched up in transit? :)
[21:28:36] <nuria>	 bblack: jaja, no, was wondering if we will see pageviews in kafka just like anything else
[21:28:43] <nuria>	 *everything else
[21:30:48] <bblack>	 ok :)
[22:43:27] <legoktm>	 bblack: hmm, I'm seeing weird stuff re: A-L & fixcopyrightwiki
[22:43:33] <legoktm>	 km@km-pt ~> curl -I "https://fixcopyright.wikimedia.org/wiki/Main_Page" | grep vary
[22:43:33] <legoktm>	 vary: Accept-Encoding,Cookie,Accept-Language,Accept-Language,Accept-Language
[22:43:40] <legoktm>	 is it supposed to be there 3 times?
[22:43:54] <legoktm>	 note that MW isn't even outputting vary: A-L yet, so I guess that would add a fourth
[22:51:21] <legoktm>	 I'll comment on the ticket
[22:51:53] <wikibugs>	 10Traffic, 10Operations, 10Patch-For-Review: Sort out HTTP caching issues for fixcopyright wiki - https://phabricator.wikimedia.org/T203179 (10Legoktm) [15:43:27] <legoktm> bblack: hmm, I'm seeing weird stuff re: A-L & fixcopyrightwiki [15:43:33] <legoktm> km@km-pt ~> curl -I "https://fixcopyright.wikimedia....
[23:22:59] <bblack>	 legoktm: ack, looking
[23:41:44] <wikibugs>	 10Traffic, 10Operations, 10Patch-For-Review: Sort out HTTP caching issues for fixcopyright wiki - https://phabricator.wikimedia.org/T203179 (10BBlack) Should be fixed now, pending caches clearing out old results.  I don't think it actually harms anything in the meantime.
[23:43:47] <legoktm>	 bblack: thanks :)
[23:55:38] <wikibugs>	 10Traffic, 10Operations, 10Patch-For-Review: Sort out HTTP caching issues for fixcopyright wiki - https://phabricator.wikimedia.org/T203179 (10Legoktm) Great :) And the special page TTL was fixed in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/EUCopyrightCampaign/+/457097 to be 24h.
[23:57:27] <bblack>	 np!