Parse current hostname from APP_ORIGIN #2179

Push knowledge of hostname up to enable to configure only one #2179

Write a test to expose the bug #2179

Write a test list #2179

Our Helm release needs to be upgraded, probably to latest. The container registry reference in there was fixed last year.

Email from AWS related to our account:

Hello,

Starting April 3, 2023, the Kubernetes project will stop publishing community-owned images (known as community images) to the old image registry `[k8s.gcr.io](http://k8s.gcr.io/)` as announced in the following blog [1]. The `[k8s.gcr.io](http://k8s.gcr.io/)` registry will be frozen. No further images for Kubernetes and related sub-projects will be pushed to the registry. If deemed necessary, the Kubernetes project reserves the right to remove existing community images from the old registry. EKS clusters by default are not dependent on images hosted in the community-owned registry. If your applications are configured to use community-owned images from the legacy registry, you may experience availability issues. You can avoid the issue by updating your application and its dependencies to pull images from the new image registry: `[registry.k8s.io](http://registry.k8s.io/)`. The new registry contains all the community images and image tags from the old registry.

What is the problem?
On November 28, 2022, the Kubernetes project announced that it would move community images from the `[k8s.gcr.io](http://k8s.gcr.io/)` registry to a new community owned registry: `[registry.k8s.io](http://registry.k8s.io/)` [2]. This new registry spreads load across multiple cloud providers and regions, functioning like a content delivery network (CDN) for Kubernetes container images. This change reduces the project's reliance on a single entity and provides a faster download experience for users. While the Kubernetes project changed the default to the new image registry, the old registry was still supported. Starting April 3, 2023, the old `[k8s.gcr.io](http://k8s.gcr.io/)` registry will be frozen. The Kubernetes project will stop publishing community images to the old registry. Existing community images in the registry could be removed in the future. Your applications may carry availability risks if your deployments are dependent on images hosted in the old `[k8s.gcr.io](http://k8s.gcr.io/)` registry.

How can you identify if you are impacted?
For step by step guidelines on identifying community images your applications are using from the legacy registry, please refer to image registry redirect documentation [3].

You can also run the new kubectl plugin community-images to identify resources running in your Amazon EKS cluster that are pulling community images from the old image registry. You can find instructions to install and run the community-images plugin here [3].

Alternatively, you can identify pods running in your cluster that are using community images from the old image registry using kubectl to list the images used by pods. You can find the kubectl command here [4].

How can you resolve the issue?
After you have identified the applications that are pulling community images from the old image registry, update your resource definitions for resources such as pods, deployment manifests, and Helm charts. In your resource definitions, change the image registry for container images from `[k8s.gcr.io](http://k8s.gcr.io/)` to `[registry.k8s.io](http://registry.k8s.io/)`. This will ensure that all subsequent image pull requests are made to the new image registry. The community has set up auto redirects to `[registry.k8s.io](http://registry.k8s.io/)` for now, but we strongly recommend that you update your resource definitions to use the new registry to future proof your cluster from any instability as per the recommendation from the community [5].

We are continually posting updates and guidelines through our AWS Blog [6], EKS Newsletter [7] and AWS Container from the Couch videos [8] to help you navigate this transition with ease. If you have any questions or concerns, please reach out to AWS Support [9].

[1] https://kubernetes.io/blog/2023/02/06/k8s-gcr-io-freeze-announcement/#timeline-of-the-changes
[2] https://kubernetes.io/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/
[3] https://kubernetes.io/blog/2023/03/10/image-registry-redirect/#how-can-i-find-which-images-are-using-the-legacy-registry-and-fix-them
[4] https://github.com/kubernetes-sigs/community-images#kubectl-community-images
[5] https://kubernetes.io/blog/2023/02/06/k8s-gcr-io-freeze-announcement/#what-s-next
[6] https://aws.amazon.com/blogs/containers/changes-to-the-kubernetes-container-image-registry/
[7] https://eks.news/
[8] https://www.youtube.com/shorts/5RvrkLPImGQ
[9] https://aws.amazon.com/support

Sincerely,
Amazon Web Services

Rough impact analysis:

$ kubectl describe pods --all-namespaces | grep "Image ID" | grep k8s.gcr.io
    Image ID:      k8s.gcr.io/ingress-nginx/controller@sha256:55a1fcda5b7657c372515fe402c3e39ad93aa59f6e4378e82acd99912fe6028d
    Image ID:      k8s.gcr.io/ingress-nginx/controller@sha256:55a1fcda5b7657c372515fe402c3e39ad93aa59f6e4378e82acd99912fe6028d

Extract function to allow fast testing #2179

Explicitly switch tabs using regex on URL #2153

Update koa-bodyparser types to access request body safely #2163

Update koa-passport to 6.0.0 #2163

Workaround for out of date @types/koa-passport, can be removed when this pull request is merged: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/64621

Remove unnecessary setup #2153

Extract respond journey #2153

Extract logout journey #2153

Extract signup journey #2153

Continue extracting and naming journeys #2153

Extract to separate a specific journey #2153

Remove a no longer required add-group command #2153

Rename for precision #2153

Save the start of journey as late as possible #2153

Always return to the start of the most recent journey #2153

End the journey when we redirect back to the start #2153

Continue collecting start of journey code #2153

Continue encapsulating session usage #2153

Remove superseded test #2153

Make button text unique for robust selection #2153

Explicitly remove session redirect property #2153

Write a passing test to avoid regression #2153

Refine the test to be a single journey with one expectation at the end #2153

Express intent with a todo test #2153