eranco74 / bootstrap-in-place-poc

Apache License 2.0
29 stars 38 forks source link

Use coredns to ease install on baremetal #13

Closed karmab closed 1 year ago

romfreiman commented 3 years ago

I'm not sure I like it. It will affect the testing

romfreiman commented 3 years ago

And might hide some gaps.

markmc commented 3 years ago

It's also important to distinguish things we put in place to make development easier, versus things we recommend real-world users do (and therefore that we should support)

If we wanted to use coredns to make development easier (by making it easier to replicate a real-world environment, in this case where an external DNS server is configured with the *.apps wildcard), I'd say we should run it on the development machine ... not on the node.

If we think this is a useful thing for real-world users to do, then we need to think carefully about how we enable it - we would not, for example, document that they hand-craft a coredns static pod and its configuration file, and merge that into the machine's ignition

eranco74 commented 3 years ago

This is definitely helpful development, our current POC works only for Libvirt VMs and whenever someone tries it on baremetal they forget to setup DNS. I think this might be useful for real-world as well so I think we can start with this PR adding it on top of the openshift-installer generated ignition. We should start drafting an enhancement for adding this functionality to bootstrap-in-place single node.

markmc commented 3 years ago

Setting up DNS is currently a prerequisite that must be made clear to real-world users

If we believe something like this is a good way of eliminating this prerequisite, then start with an enhancement to explore this idea and gain consensus for adding it in the installer

I would only add something like this here if we're very sure we will be adding something like it to the installer very soon

Please let's not pretend that this is prerequisite has been removed by embedding a hack (which we would not support in the real-world) in our development clusters

karmab commented 3 years ago

I wasn't expecting this to be merged, but rather to launch the discussion, so maybe an enhancement is a better place for this.

Nevertheless, I think there is a need to overcome the dns requisites we have when we deploy Openshift that don't make too much sense in a single node context.

Actually, it's not that much about easing development, libvirt dns records are fine for that, although the proposed procedure allows to deploy SNO anywhere, baremetal or other virtualization platforms without any further requirement (even libvirt with a bridged ip).

Finally, if it was to be implemented, it would be better to have it as part of the ignition generated by the single-node-ignition subcommand instead of hacking the generated master ignition.