4 ms·
This reminds me of the time that Google’s Paris data center flooded and caught on fire a few years ago. We weren’t actually hosting compute there, but we were h
by SOLAR_FIELDS 1y ago
This reminds me of the time that Google’s Paris data center flooded and caught on fire a few years ago. We weren’t actually hosting compute there, but we were hosting compute in AWS EU datacenter nearby and it just so happened that the dns resolver for our Google services elsewhere happened to be hosted in Paris (or more accurately it routed to Paris first because it was the closest). The temp fix was pretty fun, that was the day I found out that /etc/hosts of deployments can be globally modified in Kubernetes easily AND it was compelling enough to want to do that. Normally you would never want to have an /etc/hosts entry controlling routing in kube like this but this temporary kludge shim was the perfect level of abstraction for the problem at hand.
- citizenpaul 1y ago> temporary kludge shim was the perfect level of abstraction for the problem at hand. Thats some nice manager deactivating jargon.
- SOLAR_FIELDS 1y agoYeah that sentence betrays my BigCorp experience it’s pulling from the corporate bullshit generator for sure
- johndubchak 1y ago+1...hee hee
- LPisGood 1y agoManager deactivating jargon is a great phrase - it’s broadly applicable and also specific.
- ct_list 1y ago[dead]
- jordanb 1y agoCouldn't you just patch your coredns deployment to specify different forwarders?
- SOLAR_FIELDS 1y agoProbably. This was years ago so the details have faded but I do recall that we did weigh about 6 different valid approaches of varying complexity in the war room before deciding this /etc/hosts hack was the right approach for our situation
- nahumba 1y agoThis is the en of the thread of the first comment. Now i can find below the second comment