Earlier quoted context omitted.
Do you have a support plan?
Why should you need a support plan for a product you're paying for? "Ok, you can pay us $X/mo for the service, but if something goes wrong, we won't help you unless you also pay an additional $Y/mo." It's absolute garbage that this is where the industry is.
A Google Cloud support engineer solves a tough DNS case
101–110 of 283 posts
Re: A Google Cloud support engineer solves a tough DNS case
#102Earlier quoted context omitted.
Wait what does it have to do with the finance team? We did get their “platinum” tier or whatever.
If you're spending that much money (this isn't GCP specific -- this is any cloud) you should be establishing a 1-3 year min-commit contract, and in practice, this will get negotiated through the CFO. This will get you massive discounts -- 20-30% under list price, in exchange for spending $X million/year over Y years. It will also get you a dedicated sales rep and sales team, and they will absolutely crack the whip on…
> and they will absolutely crack the whip on internal teams to get issues resolved
Not in my experience. Although we did get an ever-rotating rep. I think they changed three of them in like a year or so
Re: A Google Cloud support engineer solves a tough DNS case
#103That brings up another point. Should the kernel standardize on unsigned scalars completely? How many legitimate use cases are there to use signed scalars in the kernel?
Re: A Google Cloud support engineer solves a tough DNS case
#104This is a fun debugging story, but is a great example why servers should be cattle not pets. Having trouble with a VM? Blow it up and get a fresh one. Still having trouble? The provisioning steps are codified, you can walk through them and find the one that causes the issue.
Did you read the article? The customer had set `net.core.rmem_default = 2147483647` on purpose. Which exposed a Kernel bug. The whole herd would be having the same issue.
Re: A Google Cloud support engineer solves a tough DNS case
#105Re: A Google Cloud support engineer solves a tough DNS case
#106Long-term solution - Use rust
Re: A Google Cloud support engineer solves a tough DNS case
#107Earlier quoted context omitted.
What is a reason why that file would correspond to the actual sysctls in effect?
If you use an automated configuration management system such as Puppet, you don't ever run sysctl manually in a shell. Instead, everything is controlled by the configuration management system. sysctl is a bit problematic in terms of exhaustiveness. That is, how do you ensure that the kernel only has its original values plus whatever you put in sysctl.conf, and nobody actually ran sysctl manually at some point? But it…
Re: A Google Cloud support engineer solves a tough DNS case
#108The former's sizes change based on platform, cpu, and compiler; the latter are fixed-width (or flexible, where _fast may use a larger size if it's faster).
I started brushing up on my C recently and have been collecting these little nuggets: https://gist.github.com/peterwwillis/53cd9d34d8755784e483790...
Re: A Google Cloud support engineer solves a tough DNS case
#109Earlier quoted context omitted.
Can you expand on your answer. How does Rust resolve this issue? Does it solve by disallowing type casts thereby preventing overflow when the number becomes negative?
I think this person is trolling. However, for the purposes of discussion, two things here: So, in Rust, overflow panics in debug builds, but does wrap around in release builds. So, it is possible this bug would have been caught in testing, but if it wasn't, it still would have slipped into production. However, that being said, Rust does not do implicit casting between numeric types. So it's very likely that this code…
Re: A Google Cloud support engineer solves a tough DNS case
#110This is a fun debugging story, but is a great example why servers should be cattle not pets. Having trouble with a VM? Blow it up and get a fresh one. Still having trouble? The provisioning steps are codified, you can walk through them and find the one that causes the issue.