Using Kubernetes from https://k3s.io/ for local development, we don't
have a weekly-snapshots-retain-4 storage class, so we need local-path.
Also, local-path doesn't allow ReadWriteMany -- but we don't need that
anyway since all of our containers are running in the same pod, and
therefore on the same node. ReadWriteMany is only required for volumes
being mounted from different nodes.

I'll put the namespace back everywhere eventually. But for local dev, we
don't (yet) need a namespace.

The `data:` key tells Kubernetes these are base64-encoded values. If
they are not encoded, the `stringData` key is correct.

These are the same values found in the .env file checked into the repo,
so this commit is not exposing any actual secrets, just the ones we use
during local development.

This creates a container that will hold the Git repo and allow us to
push to it. Next we'll set up the frontend and backend containers to
watch that repo.

The "localdev" task does everything needed to get a Git container up and
running, but does not (yet) create a .ssh/config entry for you.

This will enable us to run `skaffold dev` and have a live-reloading
version of our app running in Kubernetes.

The hasura container was being OOMKilled, so we'll try bumping its
memory allocation and its hard limit.

Long-term, we need to specify exactly which clients (e.g., the frontend
box) are allowed to connect, but AllowAnyOrigin is good enough during
dev work.

All k8s deployment files now use the "languagedepot" namespace. To use
that namespace by default and not have to specify `-n lanugagedepot` all
the time, add `namespace: languagedepot` to your ~/.kube/config file in
the appropriate context stanza, just after the cluster: and user: lines.

Now the login process will redirect to a server page, forcing a cookie
reload so that the rest of the app will correctly get the user from the
load() function in src/routes. This will mean that the user store should
no longer be stale.

The `crypto.subtle` module is a browser-only module; if we're doing
server-side rendering then we need the NodeJS equivalent.

Docker desktop's embedded Kubernetes doesn't have an ingress controller,
so part of local k8s dev must include deploying one. It also doesn't
have local-path storageClass, so we have to use hostpath.

Recent docker images of Node 20 have an issue where node-gyp's
postinstall step can fail because it's trying to replace a binary while
it's still running. Moving to Node 18 Docker images, just for now, to
avoid the problem.

Can't pre-hash the password if the page was SSR rendered, so as long as
we're on Node 18, we need to turn off password prehashing.

If there's a tls config block in the ingress deployment YAML, it sets
HSTS for dev.languagedepot.org even though the TLS is only configured
for staging.languagedepot.org, and that causes issues. In the future
we'll use kustomize.yaml to configure this.

Port issues here

Currently not working: Hasura is saying "inconsistent metadata" and
claiming that the tables Projects and Users don't exist.

Since Hasura needs the backend to be up and healthy before it will
accept its metadata, we change `wait-db` to `wait-lexbox` in the Hasura
container (and the lexbox deployment no longer waits for Hasura, but
instead waits for the database to be up and running).

This file will end up containing all PersistentVolumeClaims, so that it
can be deployed separately from skaffold

This way skaffold won't consider that it deployed the persistent volume
claims in pvc.yaml and won't clean them up after skaffold dev.

So that if it's run first, it can still deploy into the languagedepot
namespace. The duplicate namespace.yaml won't cause any issues.

Work in progress

Backend and ui containers were getting OOM killed because the build
process uses more memory than we had allocated. Eventually we'll want
these values to be dynamically replaced by skaffold dev so that the
memory allocations for the deployed app stay low.

The dotnet watch command is memory-hungry, and if the memory request is
too low, the container gets OOM killed and then the new dotnet watch has
to re-restore all the packages, which takes a while. Upping the memory
limit means that dotnet watch is able to do its job properly.

Eventually we'll want this to be done only on dev and staging.

Instead of mounting the hasura-metadata volume, we'll just go back to
inserting it as part of the Docker metadata. There's no reason to add
the complexity of trying to sync the volume. If the metadata changes,
we'll just let skaffold rebuild the Docker image.

Now you will run `task k8s:db-up` (which may become just `task db-up`
and will eventually be folded into `task infra-up`) to bring up the
database, so that it will be persistent and will not get torn down when
you exit skaffold dev. Then once you run `task db-up`, you can run
`skaffold dev` and it will have the database ready for you.

Now that the database is persistent, the only time Hasura will give an
error is the first time you spin up the whole system, when the database
is completely empty. And even there, we may be able to avoid that by
having an initContainer to check that `SELECT * FROM Projects LIMIT 1`
returns one line rather than zero, which means that the database has
been populated by the backend's SeedingData.SeedDatabase task.

This allows us to run `skaffold dev` using docker-desktop, but leave the
original config in place for staging.

Updated database startup procedures to handle migration requests with
added condition on development environment or command line argument.
Introduced conditional autoExecuteMigrations in AddLexData to only
AddHostedService when in development environment. Updated
TestServicesFixtures to build service providers with migrations applied.
Adjusted DbStartupService to throw exception when migrations are not
executed, improving error visibility. Furthermore, added logging to
track migration application duration.

The lexbox pod will be running DB migrations on startup, and the Hasura
container needs to see a current DB version (with all migrations run) at
the time it starts up. So we put both containers in the same pod and use
an initContainer to run the migrations.

Both the backend and frontend builds benefit greatly by caching NuGet or
NPM packages from build to build, using Docker's built-in caching
mechanism. You get warnings from pnpm that cross-device symlinks are not
allowed (becuse the pnpm store is located on the cache volume), but it
falls back to copying the NPM package files rather than symlinking them,
which still saves a lot of time compared to downloading them.

This doesn't work: the custom storageClass does retain the data, but
then the next PVC is considered a *different* claim and doesn't grab the
retained data. We'll go for a simpler solution where we just cache the
packages in the Docker image.

With the backend and frontend in slots 0 and 1 of the dockerfile
definitions, it's far less likely to accidentally mess up which
Dockerfile is associated with which container.

It makes a little more sense for the backend to be built first and the
frontend second.

We've decided to run skaffold with `--cleanup=false` so that it won't
delete the dpeloyments (and persistent volumes!) that it creates. That
way our task of setting it up is much simpler.

Released last week, has some bugfixes that might help.

Staging config should only know about staging.languagedepot.org; we can
add the dev.languageforge.org in a patch in dev/kustomize.yaml.

The Node bug only triggered on certain Linux kernel versions, and the
latest Docker Desktop release has a version that doesn't trigger the bug
any more. So we can go back to using the latest version of Node in the
frontend build.

Vite only listens on the loopback interface by default, which is fine
for local development but doesn't work in a Kubernetes container, where
the container is assigned its own cluster-local IP address that you're
supposed to listen to. Telling vite to listen to 0.0.0.0 means "all
available interfaces" which is what we want for k8s dev.

On dev, the lexbox container is running on port 5158, **not** on port
80. So the ingress controller couldn't talk to it, which explains all
the 502 errors I'd been seeing until now.

These profiles let you run the frontend, or the frontend *and* the
backend, locally.

Should avoid a problem where ASP.NET Core listens on the wrong interface

Some of the changes in develop created package conflicts, which are
solved by upgrading the SIL.Core and SIL.Chorus packages.

…ssing ports for doing dotnet locally.

# Conflicts:
#	deployment/base/lexbox-deployment.yaml

… dev

…sing env variable for hgweb

…via port forwarding in dev

Adding lines to /etc/hosts isn't actually needed on Linux, but is
necessary on Windows, so we'll mention that. And we'll rearrage the
README to put the extra setup steps immediately after the setup.

This reverts commit 7adca7c.

This was an early attempt at getting k8s working for local dev,
obsoleted by using skaffold.