[09:48:43] <elukey>	 hello on-callers, as FYI Valentin just moved the docker-registry's LVS VIP to IPIP/Maglev (https://phabricator.wikimedia.org/T387294)
[09:49:01] <elukey>	 I tested it and nothing weird was registered, but keep an eye on deployments etc.. 
[09:50:41] <jelto>	 ack thanks for the update
[09:52:16] <fabfur>	 thank
[17:01:31] <inflatador>	 I borrowed some hosts from the prod elastic cluster to go to relforge...my test is over, and I'm putting them back. Should I rename with their original names, or add them as all-new hosts?
[21:43:15] <inflatador>	 I'm seeing `-wmf11377                                 1H IN A 10.65.3.250` in a diff while I'm running the rename cookbook, is anyone expecting this?
[22:12:52] <mutante>	 inflatador: that's an elastic machine. I saw chatter about repurposing elastic machines for relforge or the other way around.. so that would be:
[22:12:56] <mutante>	 bking
[22:13:03] <mutante>	 https://phabricator.wikimedia.org/rONEDba7d0d85ad4445de0bc753f721988d7b29890de2
[22:13:15] <mutante>	 https://phabricator.wikimedia.org/T387782
[22:13:17] <inflatador>	 mutante I am bking ;)
[22:13:24] <mutante>	 lol, damn:)
[22:13:39] <mutante>	 well, it's the cookbook that you ran to rename ?
[22:14:10] <mutante>	 I guess it's a bug
[22:14:15] <inflatador>	 yeah, I think VRiley was maybe dealing with the other one? I saw she had the cumin lock for awhile
[22:14:18] <mutante>	 because the wmf tag should not change
[22:14:47] <VRiley>	 Which one was that? I thought I closed it?
[22:15:03] <mutante>	 elastic1109 
[22:16:25] <mutante>	 "device 5074" to be really specific. that number should definitely not change:  https://netbox.wikimedia.org/dcim/devices/5047/
[22:16:51] <mutante>	 argg. except I can't type. 5047 
[22:16:55] <inflatador>	 I ran the rename cookbook and it showed a DNS change that was unrelated to mine (see above). I bailed on the cookbook and waited a few mins and I didn't see that again
[22:17:28] <inflatador>	 I don't think the above DNS change had anything to do w/my renames, just posting it for awareness
[22:18:29] <mutante>	 is the rename cookbook just running a full decom followed by a new install?
[22:18:46] <mutante>	 in that case maybe it's normal that it first removes all DNS and then adds it back
[22:18:47] <VRiley>	 I'm not sure I ever logged into that one?
[22:19:56] <inflatador>	 VRiley nah, the elastic stuff is fine. I've just never seen a diff for `wmf` entries like that before. Sounds like mutante has a better idea of what those are for ;)
[22:20:05] <mutante>	 10.65.3.250 is that elastic host
[22:20:09] <mutante>	 it does seem related
[22:20:30] <mutante>	 250.3.65.10.in-addr.arpa domain name pointer elastic1109.mgmt.eqiad.wmnet.
[22:20:33] <mutante>	 250.3.65.10.in-addr.arpa domain name pointer wmf11377.mgmt.eqiad.wmnet.
[22:20:37] <mutante>	 these are the same thing
[22:20:44] <inflatador>	 that looks right then
[22:20:44] <mutante>	 it's normal that the mgmt entry has 2 DNS names
[22:21:00] <inflatador>	 ah, OK...thanks. Sorry for the confusion
[22:21:04] <mutante>	 one includes the server name and the other is our internal WMF "asset tag"
[22:21:12] <mutante>	 that second one should not change on renames
[22:21:24] <mutante>	 but I imagine it's still normal that it temp removes it and then adds it back
[22:21:38] <mutante>	 due to the way the cookbook runs
[22:26:58] <inflatador>	 yeah, I did it the whole repurpose/rename thing a few weeks back and it worked pretty well
[22:27:56] <mutante>	 in case you see that diff again you can check if that "wmf" name matches the host name via looking it up in netbox