search

RedHat-EMEA-SSA-Team / hetzner-ocp4

Installing OCP 4 on single bare metal server.
Apache License 2.0
182 stars 114 forks source link

Rename to libvirt-ocp4 ? #232

Open rbo opened 1 year ago

rbo commented 1 year ago

The Idea cam up in #231

Quote from @debovema

I used this repository to create an OCP cluster on an already provisioned bare metal server running Rocky 9 (on Scaleway btw, not Hetzner). Maybe this repository should be renamed libvirt-ocp4 and leave the 00-provision-hetzner.yml playbook optional ?

Indeed, libvirt-ocp4 sounds good. And 00-provision-hetzner.yml is optional since the first day.

They call it the "Danger Zone" but it's not that dangerous I think since when you rename a repo, the old name redirects on the new one. For instance see https://github.com/debovema/DO288-applications which I renamed from https://github.com/debovema/DO288-apps (forked from https://github.com/RedHatTraining/DO288-apps). The

I want to test by my own first:

This repo (I mean https://github.com/RedHat-EMEA-SSA-Team/hetzner-ocp4) is very interesting as it bridges the gap between do-it-yourself, tedious, bare-metal installation and the "too limited" OpenShift Local (formerly CodeReady Containers).

The main drawback I find however is the prioritization of information for a newcomer. For instance:

do we really need Hetzner machines ? short answer seems to be no

Right, definitely: NO - I used these playbooks to install ocp4 on server all bare-metal server. That's why you can disable dns_provider too. 

can we execute the playbooks remotely (from our laptop) ? it seems that yes but I had difficulties so I run it from the server directly

We (@ableischwitz & I) made some changes in devel tree to get it running. So please try it again with devel tree.

I'm experiencing the repo in-depth and doing some PR (add Gandi DNS Provider for example).

Then I can help to update documentation if you want.

Support / PR is always highly appreciated!

fc7 commented 1 year ago

Small comment on

And 00-provision-hetzner.yml is optional since the first day.

It seems to run automatically whenever certain values are present in cluster.yml, for instance in my case it ran even though I had set up Linux on the root server prior to running the playbook, but nevertheless wanted the DNS setup and the creation of the Let's Encrypt cert to be automated. I might be wrong but I believe as soon as dns_provider is set to hetzner, 00-provision-hetzner.yml is executed. It would be better IMO to add a separate parameter to cluster.yaml to conditionally execute it.