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. _______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
