needed two syncs: one to install the CRDs and another for the rest. Scanning on staging is in progress.

deployed to staging and production

image mirrored at https://github.com/orgs/wbstack/packages/container/package/silo

Therefore, seamlessly upgrading from minio to silo isn't required, and the whole local cluster can be blown away and recreated, which I think should avoid this issue of conflicts with existing k8s objects.

• Yes, 100%. For this dev deployment, in-place k8s resource migration is not needed (and probably not desirable).

I found a drop-in replacement fork called silo: https://github.com/pgsty/silo

It seems this is not easily possible with our existing terraform configuration if I understand it correctly, as we don't manage the "organization" in terraform. At least we would need to set the quota project: https://docs.cloud.google.com/docs/authentication/troubleshoot-adc#user-creds-client-based
Maybe it's worth to think about settings this without including it in the IaaC configs.

8.6.0 google provider version in fact applied cleanly.

Thanks for your input!

note: we opted for a wildcard allowlist after the friction we encountered during adding this component: https://github.com/wbstack/charts/pull/230

added https://github.com/wmde/wbaas-deploy/pull/3151

looks great, thanks!

Previous reviews uncovered a subtle bug/mismatch between UI/API expected response messages. I added a fix here: https://github.com/wbstack/api/pull/1288

In T435171#12255357, @Anton.Kokh wrote:

Any idea why the automated emails may be rejected?

In T436954#12316019, @Tarrow wrote:

What is this stalled on? T436530: UI: Mock Service Migration - Remaining Handlers being completed?

can confirm! nice!

i see all are merged ✅ thanks!

yay, great stuff!