gcr-cleaner VS cloud-run-faq

I also use https://github.com/GoogleCloudPlatform/gcr-cleaner

> You're right that this functionality seems to not be built into the Artifact Registry backend (and that's weird†), but it does still exist: see https://github.com/GoogleCloudPlatform/gcr-cleaner (found linked from https://cloud.google.com/artifact-registry/docs/docker/manag...), and specifically the `keep` flag for it.

No, it does not "exist". It's either builtin and then it exists, or it doesn't. What you linked is a way for me to build it myself. And I found this AND this solution is even linked in the years old Google ticket. And guess what, they didn't build it. On AWS no problem. As I said: years behind.

Sure, I can setup my own cron job (or here cloud run function / github action). But that's not what I expect from a leading cloud vendor. This is not a niche feature!

Please don't defend it, Google doesn't deserve it. Credits to whoever build the 3rd party solution, but Google really failed here.

> Depending on how you design the client, it can also "mandate manual usage" — i.e. ensure that the developer is interactively running the process for the process to proceed

Just no.

Let's face it: Google is just too incompetent to do it. Not the developers there, but the company as a whole in the way it is organized. Even IF it were as you said and it would be a philosophy, they could say that close the ticket, but it's still open.

I can list you dozens of similar things with GCP and related Google services.

I've seen a few ways to tackle this issue, notably GCR Cleaner, which is mentioned in Google's Container Registry's official documentation.

I kind of miss the point of this. So if I'm reading this right, fly.io practically only exposes the Pods API, but Kubernetes is really much more than that. I'm not very familiar with any serious company that directly uses Pods API to launch containers, so if their reimplementation of Pods API is just a shim, and they're not going to be able to implement ever-growing set of features in Kubernetes Pod lifecycle/configuration (starting from /logs, /exec, /proxy...) why even bother branding it Kubernetes? Instead they could do what Google does with Cloud Run (https://cloud.run/) which Fly.io is already doing?

I don't know why would anyone would be like "here's a container execution platform, let me go ahead and use their fake Pods API instead of their official API".

I agree with this sentiment. If your model is available as a file, yes you can use GCS and have your Cloud Function fetch it from its bucket upon start-up, but if performance matters, you should consider bundling your function into a container and running with Cloud Run instead, because you have filesystem access there (no need to make an API call to GCS if you can read it as a file).

I am building a HTTP Service running in Google Cloud Run in Go and wanted an easy way to log stuff to Google Cloud Logging.

Datastore mode had its start in App Engine's early days (launched in 2008), where its Datastore was the original scalable NoSQL database provided for all App Engine apps. In 2013, Datastore was made available all developers outside of App Engine, and "re-launched" as Cloud Datastore. In 2014, Google acquired Firebase for its RTDB (real-time database). Both teams worked together for the next 4 years, and in 2017, the next generation of Cloud Datastore was released, having merged in some of the Firebase RTDB features, and was re-branded as Cloud Firestore (in Datastore mode). This mode targets cloud compute as its users, whether serverless (App Engine, Cloud Functions, Cloud Run) or "serverful" (Compute Engine VMs, GKE/Kubernetes/Knative-compliant systems). If you provide a service via compute, use this mode.

You don't need to learn about containers unless that's something you wish to explicitly use to put together your app in a consistent, reproducible manner. Cloud Run is the service that can host your containerized app. If you are in this camp and have learned Docker, you can use that if you wish, but it's optional. Cloud Run (well, Cloud Build, the tool that builds your container for Cloud Run) can build your app by detecting what's in your app so a Dockerfile isn't needed. So like App Engine, Cloud Run can host your full-on web apps if desired. You don't even need to build the container image yourself. Both App Engine and Cloud Run deploy source code directly from the command-line, and along w/Cloud Functions, your app is generally deployed and available globally in less than 60 seconds.

Next to the docs, this page also is quite useful: https://github.com/ahmetb/cloud-run-faq

Actually meant to link this "unofficial" one.. Hope it helps a bit: https://github.com/ahmetb/cloud-run-faq

https://github.com/ahmetb/cloud-run-faq#can-i-mount-storage-volumes-or-disks-on-cloud-run