sethvargo

This is awesome - congratulations to the team on this raise. Very well-deserved :)

The context was introduced by the commenter. The original post does not use contexts. In general, there's a pretty common set of patterns in which multiple goroutines are writing data to different channels, and you need to ensure the data from those channels are processed with some level of priority.

Also, this isn't semantically correct. In order to ensure that `conditionaA` is _always_ preferred over `conditionB`, you must also check if `conditionA` has received a value inside of `conditionB`:

    select {
    case a := <-conditionA:
        return a
    default:
    }
    select {
    case b := <-conditionB:
      case a := <-conditionA:
          return a
      default:

      return b
    default:
    }

Right, which is noted in the post. That verbosity is, well, verbose. I generally need this in 20% of things I write.

It really doesn't though. It handles the case where the context might have expired or be cancelled, but there's still a race when entering the select between the ctx.Done() and reading from thingCh. You may end up processing one additional unit of work. In situations where the exit condition is channel-based, this won't work.

Additionally, this would only work if you had one predominant condition and that condition was context-based. If you have multiple ordered conditions upon which you want to exit, I can't think of how you'd express that as a range.

How would you fix that code?

Thanks, I'll take this feedback back to the team.

Disclaimer: I work for Google Cloud.

Yup - I can confirm that's the source.

Disclaimer: I work for Google Cloud.

The author of this paper alerted Google on June 11, 7:35 AM EST, less than 6 hours ago. While we recognize this is a rapidly-evolving space, a few hours is not in line with responsible disclosure[1] timelines.

While we're still preparing a proper response to the submitter, the paper makes an invalid assumption that RPI rotation and BLE address rotation are out-of-step and overlap. The BLE and RPI changes are synced; the MAC address is always rotated with the RPI/packet is rotated. We're still investigating our implementation to verify, but we do not believe this to be a vulnerability. I will reply to this thread should our investigation find anything.

[1]: https://en.wikipedia.org/wiki/Responsible_disclosure

There's quite a few resources. Liz and I did a video series https://www.youtube.com/watch?v=uTEL8Ff1Zvk and blog series: https://cloud.google.com/blog/products/gcp/sre-vs-devops-com.... It's about 50min of content, but it's framed through a slightly different lens. There's also a coursera course: https://www.coursera.org/lecture/site-reliability-engineerin...

Disclaimer: I work for Google

> Can anybody speak to the expertise of the authors on security?

I think a cursory LinkedIn or social media search for any of the title authors or chapter authors will demonstrate their credentials. There were many people involved in this book, all of whom carry the necessary credentials and experience.

> Personal questions for the responder:

Guidelines help us scale, but at the end of the day, some services are unique and require additional review. I recommend reading the bits on threat modeling for more information.

I don't think I can talk about that, sorry.

I'll flag the HTML pages with the team. I'm honestly not sure. I know we're able to offer epub and mobi this time, something not previously possible with the other books.

I haven't looked at those other resources, but I'll ask if others have.

Thanks for the feedback. This is a known issue that another user flagged this morning. The team is pursuing a fix. The content-type on the file is incorrect :/.

In the meantime, you can open it in a browser and email it to yourself. Not ideal, but a workaround.

[EDIT]: s/pursing/pursuing

This is correct. This is the third book in our SRE series. It's reliability through the lens of security.

Disclaimer: I work for Google

Great question. As an O'Reilly author myself, I can tell you that we have no control over the animal selected. There's a fun animal selection process, but the publisher's decide.

Disclaimer - I work for Google and worked on this book.

Hey everyone - Seth from Google here. Thank you for all the positive comments about the book. I'll be around to answer any questions you might have. As noted, the book can be downloaded for free in digital formats.

PDF: https://landing.google.com/sre/static/pdf/SRS.pdf

EPUB: https://landing.google.com/sre/static/pdf/srs-epub.epub

MOBI: https://landing.google.com/sre/static/pdf/srs-mobi.mobi

This feedback is super valuable - thank you for sharing. I'll be sure to relay it to the product team.

Thank you for the feedback. I'll relay this to the product team. I feel your frustration and, unfortunately, I do not have much to offer beyond my promise to relay this feedback and the items I've expressed in other responses.

> Would your team consider tweaking the pricing as I mentioned, with the goal of helping early stage startups choose GCP?

To be clear, it's not my team. I'm relaying feedback, but I can't make any guarantees or promises.

All this feedback is super valid and important, and it's being synthesized to the product team.

> They probably don't pay you enough.

Can confirm :)

> ...we do already pay for resources that are provisioned by our K8S clusters

Customers are charged for worker nodes, but until this point, the control plane ("master") nodes have been free. In addition to the raw compute costs for those nodes, there's the SRE overhead for managing, upgrading, and securing them.

> ...but I generally assumed that that cost was amortized out

<googlehat>I'm not really sure.</googlehat> <civilian>My guess would be that, initially, this was the case. However, over time, people have created many zero-node clusters. Now the amortization isn't. Again, pure speculation.</civilian>

> But, isn't that quotas are for?

See my comment above about zero-node clusters.

> I have a new $73/mo. fee attached to my account (which, is not the end of the world) is that this really comes out of left field...

Acknowledge, but I do want to highlight that changes take place a few months from now (June 2020), not immediately. Furthermore, each billing account gets one zonal cluster with no management fee.

> Is this the precursor to you all discontinuing GKE because, as the DevRel class likes to tweet, nobody should be using Kubernetes if they can use (more expensive) services like Cloud Run?

100% no. Also, Cloud Run is almost always cheaper than running a Kubernetes cluster.

> Are we about to get Oracled?

I'm not sure what you mean by that verb.

Can you help me understand how these changes would be _more_ than EKS?

Correct, but the control plane nodes _were_ free and had no SLA. This changes that. [edit: spelling]

As also a security person (:wave:), you can use dedicated node pools and workload identity to isolate workloads in the same cluster.

Hmm - have you considered a tool like Terraform or Deployment manager for creating the clusters? In general, it's best practice to capture that configuration as code.

It's not _just_ abuse. It's not _just_ the new SLA. It's also the additional functionality we've built beyond just Kubernetes and how simple we have made the offering and auto-scaling, etc.

I think you'd be interested in our Google Cloud for Startups program: https://cloud.google.com/developers/startups

Thank you <3. I apologize the email was hazy on details. I can't un-send it, but I'll work with the product teams to make sure they are crystal clear in the future. I'm interested to learn more about what you mean about outdated docs? The documentation I'm seeing appears to have been updated. Can you drop me a screenshot, maybe on Twitter (same username, DMs are open).

These changes won't take effect until June - customers won't start getting billed immediately. I'm sorry that you feel trapped, that's not our intention.

> You should keep existing clusters in the pricing model they’ve been built in, and apply this change for clusters created after today.

This is great feedback, but clusters should be treated like cattle, not pets. I'd love to learn more about why your clusters must be so static.

That's correct. Vault Enterprise (at my last math) was ~$125k/yr, so that management cost is negligible :)

Attempting to capitalize on a competitor's announcement isn't cool and doesn't look great.