You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have our own airgapped internal PKI (using HashiCorp Vault), we have our own existing PostgreSQL HA cluster (using PostgreSQL 16.3) with client certificate auth, we have our own existing HA Keycloak cluster (using Keycloak 24.0.3). We have our own stringent SSH cipher support and authentication policies, which do not conform to oVirt's.
It does not make sense for us to run separate non-HA/ad-hoc HA instances of these services for/by oVirt, especially for cases of e.g.:
[ ERROR ] Postgresql client version is '13.14', whereas the version on '[REDACTED]' is '16.3'. Please use a PostgreSQL server of version '13.14'.
(Note that 13.14 has at least one known security vulnerability which, albeit a fix has been released yesterday, my org has been patched - except oVirt, due to this heavy reliance on explicit versions.)
I understand this change was introduced to resolve a backup/restore conflict but we have our own backup infrastructure for our Postgres HA cluster, we do not need oVirt to manage its database backups for us.
I propose this:
Support using Postgres ODBC URIs instead. Change the version requirements for the database to be a minimum. If a newer server is used and there is concern about backup compatibility, that should be something the operator should be able to opt out of, because:
In many places, robust backup systems are frequently already implemented. This should not be a hard requirement, nor should the operator be pestered about opting out (or having them disabled because e.g. a newer DB server is being used).
Provide documentation and/or realm import JSON for an existing Keycloak cluster/install and do not require version-lock there as well.
Support orgs providing their own SSH keys (I find no method of using ED25519 SSH keys?) and server certificates/keys using PFX/PKCS12.
Allow specifying cipher lists for engine/node SSH.
This will also allow more rapid and focus of oVirt core itself, as e.g. even something a trivial as a Postgres x.y => x.z update in environment would not require releng.
The text was updated successfully, but these errors were encountered:
Hi.
We have our own airgapped internal PKI (using HashiCorp Vault), we have our own existing PostgreSQL HA cluster (using PostgreSQL 16.3) with client certificate auth, we have our own existing HA Keycloak cluster (using Keycloak 24.0.3). We have our own stringent SSH cipher support and authentication policies, which do not conform to oVirt's.
It does not make sense for us to run separate non-HA/ad-hoc HA instances of these services for/by oVirt, especially for cases of e.g.:
(Note that 13.14 has at least one known security vulnerability which, albeit a fix has been released yesterday, my org has been patched - except oVirt, due to this heavy reliance on explicit versions.)
I understand this change was introduced to resolve a backup/restore conflict but we have our own backup infrastructure for our Postgres HA cluster, we do not need oVirt to manage its database backups for us.
I propose this:
This will also allow more rapid and focus of oVirt core itself, as e.g. even something a trivial as a Postgres x.y => x.z update in environment would not require releng.
The text was updated successfully, but these errors were encountered: