Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

oVirt Engine (and engine setup) needs better existing infra incorporation #82

Open
nf-brentsaner opened this issue May 10, 2024 · 0 comments

Comments

@nf-brentsaner
Copy link

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.:

[ 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:

  1. 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:
  2. 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).
  3. Provide documentation and/or realm import JSON for an existing Keycloak cluster/install and do not require version-lock there as well.
  4. Support orgs providing their own SSH keys (I find no method of using ED25519 SSH keys?) and server certificates/keys using PFX/PKCS12.
  5. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant