[11:41:10] hnowlan: Hugh Nowlan: hierdata: Add stub values for changeprop (74909cb), may I merge this? [11:42:19] vgutierrez: please do! thanks, I hadn't noticed it was merged [11:42:25] ack [11:43:22] (merged) [12:52:17] <_joe_> rlazarus: I have an httpbb question :) [14:29:18] chaomodus: do you have a sec, re: the gen-zones $INCLUDE_DIR stuff, etc? I think we had this conversation once before, but I'm failing on the details of why we'd need it (vs staging the two git-driven datasets together and using relative paths that are consistent at the include-path level) [14:30:16] or maybe to expound on that a bit while I have a sec [14:31:54] what happens now for the normal deploy-check execution (CI or real deploy), is there's a git clone of ops/dns somewhere, and gen-zones copies and/or templates bits from there into some $TMPDIR which is an equivalent of /etc/gdnsd (has a zones/ subdir, etc). Then the checkconf and such run as e.g. gdnsd -c $TMPDIR checkconf [14:33:00] I would've expected we'd have the netbox checkout pulled together similar (gen-zones pulls it from a different git clone, but stuffs the output into $TMPDIR/zones/netbox/ for checkconf, which naturally becomes /etc/gdnsd/zones/netbox/ when later deployed [14:33:35] and the $INCLUDE statements are simply of the relative-path form that works for both cases: $INCLUDE netbox/10.in-addr.arpa [14:42:43] looking at the scripts again and correcting the above for how it actually works [14:43:50] gen-zones does expect the git parts to already be done, so you'd still need that added to the docker and to authdns-update mechanisms I think, and thus you maybe do need some new variable for the path where the netbox git checkout sources from [14:44:14] the part I'm saying is still maybe-unecessary is having templated includepaths in the /ops/dns zonefile templates [14:47:02] so the Dockerfile does need the git clone command, and deploy-check does need a new argument for where the netbox git clone happens to be at [14:47:41] and the authdns-update scripts on the puppet side, need updates to set that deploy-check argument correctly and handle the netbox git path as well (but I suppose, not pull clone udpates on their own) [14:48:08] (unless we're sharing that script with netbox-driven updates, in which case updating that clone can be a flag for that usecase) [14:51:01] anyways, I'll be in meeting-mode for a bit [15:02:04] _joe_: what's up? [15:03:24] <_joe_> rlazarus: can we add regex matches to assert_headers ? [15:04:01] <_joe_> my use case was - I wanted to verify the Server: header returns a hostname [15:04:12] <_joe_> and not "envoy" or "nginx" [15:04:26] yeah definitely -- I didn't want to complicate the API before there was a use case, but seems good [15:24:47] (also my power just went out, so not sure yet what today looks like) [15:26:54] <_joe_> damn [15:27:30] 🔌 🐊 [15:32:16] four hours ago, womp womp https://twitter.com/CityofTLH/status/1232990763669172224 [15:32:16] 🐊 LOL LOL [15:33:28] I was in the middle of making coffee when it went out, so weirdly I didn't even notice until a few minutes later -- my kitchen gets plenty of sunlight and the water was already hot [15:34:01] if it doesn't come back before I finish this cup, I guess I'll go get another at a coffee shop and set up for the day from there [15:40:34] cdanis: https://static01.nyt.com/images/2020/02/26/nyregion/nygator-photos-slide-TH5V/nygator-photos-slide-TH5V-mobileMasterAt3x.jpg [16:33:21] ahahaha TIL 'corking' as an adjective [16:42:45] bblack: i think the general idea is that the two data sets are strictly decoupled, and in the interest of supporting the, basically three use cases (CI, local tests and deployment) without really having to declare how the layout works (which to me seems slightly brittle) [16:43:17] bblack: that said there are some things that this has brought to mind [16:57:01] to be clear, having a direct include paoth under the generated data seems brittle to me [16:57:11] rather than having a separately maintained include directory. [16:57:31] (or directories, for example if we separated mgmt production dns or whatever) [17:23:05] ottomata: should there be anything graphed in https://grafana.wikimedia.org/d/znIuUcsWz/eventstreams-k8s?orgId=1&refresh=1m ? [17:24:32] chaomodus: yeah but neither dataset is useful without the other for very much [17:24:51] the production zonefiles won't validate with missing includes, and the netbox snippets won't validate without the surrounding zone context [17:25:18] either way, you have to bring the generated/templated/copied/whatever outputs of both datasets together to do CI or local tests or deployment [17:27:13] * jbond42 thought i was doing well [finnaly] going through the go tour untill this https://tour.golang.org/moretypes/25. so adder() is more like a struct with member var and a pointer to a function ??? :S [17:27:19] at the end of the day, the layout is implicitly part of it. Together, ops/dns + netbox-git define one thing: the valid zone data for all our zonefiles, which is otherwise incomplete. [17:28:58] if yyou want different directories for mgmt vs prod entries, then still be different subdirs, or even form a tree of subdirs [17:30:29] zones/netbox/prod/ vs zones/netbox/mgmt/ or whatever, it's still $INCLUDE netbox/mgmt/10.in-addr.arpa [17:32:34] (and to be clear, and maybe this is part of where we don't see each other's versions of these things, I'm not saying checkout the netbox git repo at /etc/gdnsd/zones/netbox. I'm saying check it out somewhere else under /srv/git/ or whatever, but that the CI/deploy scripts should pull the data together with ops/dns for CI or deploy purposes, into a unified output directory tree that can be validated [17:32:40] and can be loaded by runtime) [17:32:44] bblack: okay let me restate things and we can see if we agree with the moving parts here. In order to maintain a sense of encapsulation, it seems like the checkout should not be directly in the output dir [17:32:51] bblack: haha that's exactly what I was about to say... [17:33:16] following on the side because of prod troubleshooting, but +1 for me to what Brandon said + a simple way to know the path of the netbox checkout that works in CI, local dev and prod [17:33:21] anyway so you provide to deploy-check a copy of the checkout ~somewhere~, and then it moves the contents into a subdir of the compiled zone filses [17:33:38] that way the lets say production state is frozen together [17:33:41] right, all of that is more or less the same in our versions [17:33:45] and there's never this floating external state [17:33:57] I'm just saying I don't see the point of templated $INCLUDE vs hardcoded path-relative $INCLUDE [17:33:58] cool works for me, especially since almost all of the plumbing is the same :) [17:34:05] yep i agree [17:34:21] (the main plumbing difference is that we don't need the variable insertion) [17:34:41] and what we do with thegenerated dns dir is slightly different. [17:34:50] if that scans I can implement that right quickx [17:36:08] the main thing that's a little tricky to deal with, is three different kinds of authdns-update/authdns-local-update to execute to deploy changes [17:36:18] which will probably different on some CLI args [17:36:47] yah [17:36:51] the authdns-update that just pulls new ops/dns changes for human deploy, and uses whatever the last-known-good netbox git data was (doesn't try to pull new commits) [17:36:56] that's a problem for future cas :) [17:37:02] vs the one netbox triggers that does the opposite [17:37:10] yes [17:37:15] and maybe a version that does both, for fresh installs of dns servers doing their first data pull [17:37:52] although I guess in theory, if CI is working right before merges of either set, it should be "safe" to always update both from latest merged git for both cases [17:37:56] just might be confusing and/or racy [17:38:24] some thinking to do there [17:38:26] right, of course the authdns-update also does a deploy-cehck does it not? [17:38:32] yes [17:38:44] hbut this is, pleasenently, a decoupled problem [17:38:44] yes, authdns-update runs parallel authdns-local-update on all the boxes [17:39:11] authdns-local-update serially does: (a) update the git clone of ops/dns then (b) execute deploy-check to validate + deploy it locally [17:39:53] so from the authdns[-local]-update pov, we just need to add another git clone for netbox data, and deploy-check needs to copy that data into place before validation/deploy [17:40:31] mh yes [17:40:32] deploy-check would have an argument for where to find the updated netbox git at, which can be used for local dual-repo checks and for CI based on args from the docker.. [17:40:50] (and for authdns-update's input of the same) [17:40:59] yes [17:41:07] excatly [17:44:11] okay cool sounds like the changes are straight forward [17:44:59] awesome [17:45:06] thanks so much for the feedback :) [17:45:23] np! [18:43:14] akosiaris: only staging is deployed right now [18:43:17] still have been benchmarking [18:43:22] graphs show up when i actualy do traffic [18:43:32] i'm about to work on that now [18:45:52] ottomata: a cool, thanks! [19:25:12] just completed the upgrade of the prometheus-mcrouter-exporter (again), I fixed one bug (that I had introduced a couple of days ago) [19:25:22] if anything pops up you know who to blame