On Thu, Aug 1, 2019 at 4:56 PM Colin Walters <walt...@verbum.org> wrote:
> The OpenShift installer and Machine Config Operator are built around Ignition. MCO is not built around ignition, it's built around the ignition file format, it's a completely separate implementation. > One pitch for Ignition is that it unifies bare metal and cloud provisioning - > in RHEL you have kickstart vs cloud init. > Again, the OpenShift installer (and MCO) today is built on top of this - if > you're doing a bare metal PXE setup it works almost exactly the same as an > AWS AMI boot. This is true, *if* you're doing a PXE boot and you are in control of provisioning the infrastructure. To the point of differences between kickstart vs cloud-init, we could have baked the MCO-once from into the host (cloud init) or installed via kickstart, and processed the same ignition payload (just a question of how a kickstart host gets it, there are a multitude of options here). You'd also have the option to pre-provision your hosts, add ignition payload, run once-from. > First, you're missing a bit of the interesting bits around "extracts files" > because the MCO correctly handles *state transitions* between Ignition > configs (e.g. ensuring that old files are deleted), and this relies on it > being provisioned into a known state that wasn't written by a mix of e.g. > Kickstart and Puppet/Ansible or whatever. None of that is distro specific. It's just declarative host-configuration with limited set of modules to configure the host. It's basically a stripped-down puppet, which is fine, I like the MCO, but nothing *COS specific about it. > And the OS updates...that's just the start. Nowadays when I'm talking about > RHCOS in the context of OpenShift 4, I usually start talking about the MCO > first - and in particular that the MCO combines with RHCOS to make a > "Kubernetes native OS". > > Concrete example; we now support setting FIPS mode: > https://github.com/openshift/machine-config-operator/pull/889 > (As well as generic kernel arguments) I still see the distro as an implementation detail. The only thing I can see different from atomic vs coreos is (first) boot-time configuration. Just look at openshift-ansible today for an example of how you can integrate a non-ostree distro into the process. It's a couple packages and a few tasks. Pretty much just one role now. -- Michael Gugino Senior Software Engineer - OpenShift mgug...@redhat.com 540-846-0304 _______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev