cgwalters

Bear in mind that we're basically trying to do it both ways; We still have Red Hat Enterprise Linux, and I don't think anyone would involve the term "tech stack churn" there.

If you're using Tectonic in particular, we're certainly aiming to have a nice path. Although there are a lot of details in the term "upgrade" - it may require reprovisioning, but a lot of the idea of carrying forward Ignition is that any early OS customization you've made still applies.

If you're running a Kubernetes cluster, while Red Hat CoreOS will support automatic inplace updates just like existing CL, I'd say it's best practice to do periodic reprovisioning to flush out extra node state. For example in RHEL 7.5 we switched from devicemapper to overlayfs, but existing instances don't get automatically transitioned. If you're using k8s reprovisioning works well as all the containers just move off and then back on.

Thanks for bringing this up, this one had dropped off my radar.

I do think that the simple concept of having `toolbox` installed by default is a powerful one, and while we should revisit some of the details I'd say we should carry this one forward.

Have you built much scripting up on top of it, or is it just having it available for interactive use?

The answer to this splits across the Fedora/RHEL sides. For people using RHEL Atomic Host today (and RHEL) with OpenShift, we obviously want a good transition to Red Hat CoreOS. That gets into some details though of provisioning and what types of customization is being done today. Similar concerns apply to Tectonic+CL users.

My message on the community side (Fedora and existing CL) is - don't panic, you have some time. And a lot of us want to support a broad array of use cases.

Since you mention rpm-ostree, one thing I'd point you to is some work we did on changing the Container Linux update operator to talk to it: https://github.com/ashcrow/container-linux-update-operator/