Hetzner server types

[schonert]

This is awesome!

Would we be able to add more server types to the hetzner list? https://github.com/vitabaks/postgresql_cluster/blob/c9c9f02d0dd7991e3966f0e6c35dd4f3d3c45af0/console/db/migrations/20240520144338_2.0.0_initial_scheme_setup.sql#L295-L302

I could stitch together a PR - altho not sure if there's a good reason to limit it to these 8.

[vitabaks]

Hi. Yes, we can add other types. Which ones are you interested in?

As far as I recall, all available server types are included, except for shared CPUs, which were not added because they are not recommended for production use.

Additionally, you can modify or add types in the database of your console installation.

[schonert]

I was interested in beefier shared CPUs. So CX32 and above, CPX31 and above, and CAX21 and above.

Not under the impression that they are not recommended for production?

Additionally, you can modify or add types in the database of your console installation.

Arhh great point!

[vitabaks]

I see that only 6 types of servers are present with a dedicated CPU:

All of them are in the console database.

I was interested in beefier shared CPUs. So CX32 and above, CPX31 and above, and CAX21 and above.

Servers with shared vCPUs are not suitable for production databases because they do not guarantee consistent performance. Virtual CPUs on these servers are shared among multiple virtual machines, which can lead to unpredictable delays and reduced speed under heavy workloads. This is particularly critical for databases, where steady access to resources is essential to ensure low-latency responses and stable performance under load.

I could stitch together a PR - altho not sure if there's a good reason to limit it to these 8.

Yes, we could add all available types (with the exception of arm, since its support has not yet been implemented), but in this case it is necessary to explicitly mark the "Shared vCPU" types in the UI.

[vitabaks]

Feel free to suggest a PR

cc @schonert @nelsonic

[schonert]

I got sidetracked.

... it is necessary to explicitly mark the "Shared vCPU" types in the UI.

I was put off by the suggestion to add mark in the UI - not that I disagree. It would require me to look into how to best add an additional field to the database and then later populate the frontend.

Altho, thinking about it again, made me realise that we could just add it to the instance_name. Eg. CCX63 (Shared vCPU). Agree?

[vitabaks]

Yes, I would really like to mark shared vCPU in the user interface so that users do not accidentally choose this type for production.

Related PR #835

[nelsonic]

If we agree that the Shared vCPU / Dedicated vCPU string should be added to the instance_name, ➕
happy to include it in my current PR #835 so it's one-and-done.

[nelsonic]

#835 contains the (Shared vCPU) / (Dedicated vCPU) string in instance_name via nelsonic@2235709 👌

[nelsonic]

As noted by @vitabaks in #835 (comment), 💬
we cannot change the instance_name to include the additional string as it will mess with deployment. 👎
i.e. hetzner API will not recognise "CX22 (Shared vCPU Intel)" when attempting to create a VPS. 🚫

So will revert that last commit. ♻️

Instead, proposing adding the new shared_cpu field to public.cloud_instances as:

ALTER TABLE ONLY public.cloud_instances
ADD COLUMN 'shared_cpu' BOOLEAN DEFAULT FALSE;

Then setting the boolean as V has suggested. 👌

[nelsonic]

Please see: 025bbd3 🙏

[nelsonic]

#835 merged.

@schonert pls check if this resolves your OP. 🤞