gurrone

The film is centered around the idea of establishing an alternative to the GDP as the metric to measure success of a country/society. The film follows mostly Katherine Trebeck on her journey of convincing countries to look beyond the GDP. Since it's quite hard to view such independent movies this is a rare occasion to view it online in a virtual screening. This screening is organized by the Permaculture Institute and donation based! Hint: There is another screening one day later in case you miss the one the 29th.

That is only partially true. So you spin up a GKE cluster, setup your deployment push it out via kubectl. OK your app is running but now you need access to it. The portable way is a Service Loadbalancer but it's just a TCP loadbalancer. So you go for the Ingress API. Then you want to do it a little bit more, you learn that the Ingress controller on GKE just configures you a L7LB at Google. Nice, that can do what I want. I want it to run dual-stack IPv4 and IPv6 (my prior example for those shortcomings in GKE was setting response-header but that was added lately after only 3yrs). Oh snap supported by the LB but not by the Ingress controller. Then you dig deeper and learn that development already shifted from the Ingress to the Gateway API. And now you're already knee deep into problems, because what you want to do is not really part of the Ingress or Gateway API and now you're at the mercy of the vendor you choose. Or you run a vendor neutral Ingress controller, like the classic nginx one. That later choice means you've to make yourself familiar with the oddities of that component as well. And then you also want something for DNS, Let's Encrypt and so on. Half a dozen controller installations later you finally have something. But now you've to maintain it because the managed service is only for k8s.

But one should not forget that you also had to build up a lot of vendor specific know how in the past. Someone had to configure your F5 BigIP and your Juniper Router and the Cisco Switch and of course the Dell or HPe boxes you bought.

I take more concerns with k8s immature ecosystem which is kind of reinventing classic unix stuff for distributed computing. And that just started and you've to lifecycle components with breaking changes every few weeks. And people took issues with updating Ubuntu LTS releases every two years. Now they have to update some component every week.

... and mrsk is imperative compared to the declarative approach of swarm and k8s. Especially if you go all in on gcp and use gke + config-connector + fluxcd or argocd and all the other controller, it takes time to know and understand how successful your latest change was. In the end k8s + controller is a huge asynchronous reconciliation loop. It might succeed to apply your changes at some point in time, but you've no idea when it starts and when it ends. That often sucks and takes a lot of time. And even more time if you've to figure out which change failed and why and if it's the final state already. Some older dudes with grey hair might remember cfengine and its eventual consistency approach.

That just made me look at Google Cloud again, and it's depressing to see. At least some types of load balancer do support dual-stack setups, but not if you configure them via GKE with the k8s ingress controller. If you use that one you're out of luck and they maybe now implement it for the new gateway API controller. So if you use GKE and ingress you can configure two of them. One with a static v4 address and another one with a static v6 address. Of course you pay twice then.

Would use OpenBSD + unbound to get NAT64 + DNS64. I'd prefer a dual-stack setup with RFC1918 IPv4 internally + a NAT44 gateway and IPv6 "just" on top. Drawback: if you find yourself to have to do a lot of firewalling it essentially doubles your work.

20 years ago it was the lack of IPv6 support on the CPE holding IPv6 on the server side back, nowadays it's a lack of IPv6 at major SaaS providers causing issues. In most of the scenarios I was involved in we made sure that the CDN in front of the product was able to terminate IPv6 and left everything behind it v4 only. About 1/3 to 1/2 of the traffic received was sent via IPv6 on those setups. Maybe time to turn that around and use the CDN to make the product also available via v4? Leaves you with maintaining a NAT gateway for your own infrastructure.

BTW also only one of the office networks I had to deal with in the past 20 years hat experimental IPv6 support, and that was at a small local hosting company. Everything bigger than that also sticks to IPv4 only for now. :(

Strange how things change but still stay the same.

Same if you're lead climbing, there is a small chance (if you left a longish tail end) to clip the wrong part of the rope. If if it does not directly result in a dangerous fall you might trap yourself inside a quickdraw.

Bitbucket has it as well. When you move from Bitbucket to Github your PR workflow in the WebUI feels utterly complicated and way harder to review. I already started to use gh a few month ago and that finally puts some sanity into working with github. Beside of creating PRs and merging them you can also get the diff of the PR, and pipe it to other tools. In the most simplistic case into diffstat. That finally compensates a bit for the horrible WebUI experience. Still a tree view would be nice.