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

Reply via email to