Zero-to-jupyterhub-k8s: allow postgres in requirements.yaml

[gsemet]

Can we instantiate a postgres sql server using requirements.yml for hub.db.type = postgres?

[gsemet]

will you be interested by this feature?

[yuvipanda]

Can you explain a bit more by what you mean? Installing and maintaining a postgres db ourselves? What advantage would this give over just using sqlite?

If you want to use postgres, my current recommendation is to maintain that separately and configure the hub to use it, rather than install and maintain it as part of this chart.

[gsemet]

actually, i did this modification and was surprised how easy it is to instantiate a full postgresql server using helm requirements. The main advantage i see over sqlite it is that it allow rolling update of the hub.
of course, this could be done under a condition, typically a value such as postgres.enabled that can instantiate a postgre helm automatically for the user (without pod name colision, of course). could use, or not, a pvc, etc.
Even when not using a pvc (so data is not persistant when the pg pod restarts), it is very stable since postgres crash is really rare. So the hub is always available (thx rolling update)

I'll propose a pull request and you tell me if you like it :)

[yuvipanda]

I think we should not do this in the chart here :) Running a database is serious business, and I don't think we should get ourselves into it. We could possibly provide instructions somewhere on people who want to install and maintain one themselves, but I don't think we should put it directly in this chart. It's pretty easy to have your own 'deployment chart' that has as its requirements both the JupyterHub chart and the postgres chart, if you so wish.

Can you explain a bit more on what you mean by 'Rolling Update' here? Doesn't that already happen with the current default setup?

[gsemet]

can we at least provide the option, it is commonly found on helm charts:

• example for sonarqube, configurable by the user if it defines this value settings.
• lot of others are

[yuvipanda]

I appreciate the links and the thought you have put into it! However, given that:

1. sqlite is more than good enough for most hub use cases,
2. Using postgres on Kubernetes is a very complicated setup (see https://medium.com/kokster/postgresql-on-kubernetes-the-right-way-part-one-d174ee8a56e3 and its continuations)
3. Anyone using Postgres on kubernetes will probably have to customize it intensely
4. It's fairly easy to have your own deployment chart that composes both this chart and the postgres chart

I don't think we should add a postgres server to this chart. I do think we should add a lot more documentation on how to do this, however - there's almost none on how to configure non-sqlite databases.

I hope this makes sense?

[gsemet]

i try again :) Adding it as an example would help, but i agree a cleaner warning for user that postgres on kube with high availability is hard.
But i must admit since i have enabled it against z2jh, our hub is much more stable (sqlite does not allow rolling update).

[choldgraf]

I'm always +1 on adding more documentation in lieu of making the underlying

tech more complex :-)

On Mon, Mar 12, 2018 at 8:52 PM Gaetan Semet [e-mail]
wrote:

i try again :) Adding it as an example would help, but i agree a cleaner
warning for user that postgres on kube with high availability is hard.
But i must admit since i have enabled it against z@jh, our hub is much
stable.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/567#issuecomment-372458436,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABwSHZbFj3r6qreZ3UAL0KriBYyV2WUWks5tduALgaJpZM4Sgm_V
.

[choldgraf]

To clarify my previous comment a bit. It sounds like both of the following points are true:

1. Using postgres for the hub DB can make it more stable, and gives you nice things like rolling updates
2. For the majority use-cases, this isn't strictly necessary as sqlite is a "good enough" solution
3. For those use-cases, having a lot of information on Z2JH for setting up postgres will likely confuse people

I think that part of the problem here is that z2jh is both "total n00b" docs as well as "fancier deployment" docs. I think we should keep it aimed at the "total n00b" crowd, and link out to other resources (for now, ones that we don't maintain) for more complex deployments. So I think we should do:

1. Create a sub-section in advanced topics that mentions the potential benefits of postgres, but also states that this is not "officially" supported by the jupyterhub team
2. Link out to the postgres content which lives somewhere that is not z2jh (maybe @gsemet can make a blog post or something for now, though long-term we should have a wiki for more community-driven usage/setup patterns.)
3. Create a sub-section in the docs on using jupyterhub in conjunction with _other_ helm charts (e.g. explain what is a helm metachart and how could you use jupyterhub with one other simple helm chart as an example)

What do folks think?

[consideRatio]

Closing this issue now as discussion since have aligned towards not letting z2jh grow further by adding other chart dependencies, and that I personally believe it is a bit to hard for z2jh maintainers to keep docs updated about this.