[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Follow up on OKD 4



On Wed, Jul 24, 2019, at 10:40 AM, Michael Gugino wrote:
> I tried FCoS prior to the release by using the assembler on github.
> Too much secret sauce in how to actually construct an image.  I
> thought atomic was much more polished, not really sure what the
> value-add of ignition is in this usecase.

The OpenShift installer and Machine Config Operator are built around Ignition.

>  Just give me a way to build
> simple image pipelines and I don't need ignition.  To that end, there
> should be an okd 'spin' of FCoS IMO.

Yes, this is what https://hackmd.io/ZOQo-1VnRNOrgIcGosq29A proposes.

>  Atomic was dead simple to build
> ostree repos for.  I'd prefer to have ignition be opt-in. 

This is a bit of a side discussion, but rpm-ostree hasn't changed at all; we still support e.g. using it with Anaconda upstream.  But it's also true that the focus is now on the "CoreOS model" which pairs (Ignition, ostree) and that's what coreos-assembler is for.

> Since we're
> supporting the mcd-once-from to parse ignition on RHEL, we don't need
> ignition to actually install okd.  To me, it seems FCoS was created
> just to have a more open version of RHEL CoreOS, and I'm not sure FCoS
> actually solves anyone's needs relative to atomic.  It feels like we
> jumped the shark on this one.

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.

> I'd like to see OKD be distro-independent.  

> MCD is good software, but there's not really much going on there that can't be ported to any other OS.  MCD downloads a payload, extracts files, rebases ostree, reboots host.  You can do all of those steps except 'rebases ostree' on any distro.

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.

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)

But this is all still just the beginning for the MCO, next up may be SELinux:
https://github.com/openshift/machine-config-operator/issues/852
And you get the idea.

Obviously, we could support kernel arguments on e.g. Ubuntu too.  And FIPS, etc.  But...the engineering cost starts to add up.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]