Invenio is hard to deploy for non-prod (dev/test) purposes

[lindhe]

Is your feature request related to a problem? Please describe.

Currently, it is very hard to install a non-production variant of Invenio using the Helm chart. This stems from the fact that Invenio requires a (routable?) FQDN with TLS configured. For prod, this is clearly a good thing. But during development, this is actually quite impeding for a number of reasons:

• It requires significant platform infrastructure in place, which may not be available in dev environments like minikube.
• It exposes dev variants publicly, which may not be desirable.
• It requires unnecessary use of shared resources (domain name and TLS certificates), which requires annoying amounts of coordination between developers and teams and organizations to avoid collisions and rate limiting.
• It takes more time to setup, which is not desirable for a dev environment.

I do not understand the internals of Invenio well enough to fully articulate exactly what configuration changes are needed for this to work.

Describe the solution you'd like

I wish it was possible to deploy Invenio without setting a FQDN or configuring a TLS certificate. This should, ideally, not require a ton of custom variables to be set in the configmap or whatever, but be very easy to configure. Ideally, I would like it to be the default so it's dead simple to get going with something in a dev environment (like in minikube). Prod environments will always require custom values and different configuration depending on their security requirements and other context, so I think it makes sense to have "dev" be the default and let prod be configured manually. Also, dev installs happens more frequently than prod installs, typically.

I do not want a solution that requires manual TLS certificates to be issued. PKI and certificate management is hard, so it must be automated in my opinion. Also, cert-manager with Lets Encrypt is such a common setup that I think it's worth supporting.

The setup I envision would require the user to run kubectl port-forward svc/web 8080:80 and can then browse http://localhost:8080 to use Invenio. This will not make use of Ingress or Route objects.

Describe alternatives you've considered

In my current context, I have an ingress controller in Kubernetes and cert-manager configured with a Lets Encrypt cluster issuer. Together with a wildcard DNS, this lets me iterate on Invenio and change the domain name each time I get rate limited by Lets Encrypt. So I use invenio-dev-1.example.com until the number of crashes/restarts with bad versions hits the rate limit. Then I change to invenio-dev-2.example.com and then invenio-dev-3.example.com, and so on. This works, but is far from ideal since it's so wasteful with domains and certificates and other shared resources.

[lindhe]

If I recall correctly, a major blocker for this was due to using access mode ReadWriteMany on the volume (which is rarely supported on simple single-node systems). But it should be possible to use ReadWriteOnce instead, as long as everything is scheduled on the same node.