Skip to content

Rebase RHEL CoreOS 4.6 on Fedora CoreOS Live ISO/installer #210

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 14, 2020
Merged

Rebase RHEL CoreOS 4.6 on Fedora CoreOS Live ISO/installer #210

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
95 changes: 95 additions & 0 deletions enhancements/rhcos/liveisoinstall.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,95 @@
---
title: RHEL CoreOS Live ISO/installer
authors:
- "@cgwalters"
reviewers:
- "@coreos-team"
approvers:
- "@coreos-team"
creation-date: 2020-02-07
last-updated: 2020-02-07
status: implementable
---

# Rebase RHEL CoreOS 4.5 on Fedora CoreOS $latest

## Release Signoff Checklist

- [ ] Enhancement is `implementable`
- [ ] Design details are appropriately documented from clear requirements
- [ ] Test plan is defined
- [ ] Graduation criteria for dev preview, tech preview, GA
- [ ] User-facing documentation is created in [openshift-docs](https://github.com/openshift/openshift-docs/)

## Summary

RHEL CoreOS is built from RHEL components, but uses configuration and tooling from Fedora CoreOS. They share many things such as the installer code, etc.

This enhancement tracks rebasing RHCOS 4.5 on the latest FCOS code, in particular the installer.

### New "Live" installer

Currently, RHCOS 4.4 and below offer a kernel/initramfs and ISO that can run a shell script installation program from the initramfs.

In FCOS $latest, there is a Live ISO/PXE media that runs the full OS (for example, it includes `podman`), and a completely revamped [coreos-installer](https://github.com/coreos/coreos-installer/).

## Motivation

This allows administrators to run arbitrary code before and after the installation process by providing Ignition that wraps the installer. For example, higher level tooling like Foreman and Ironic can easily `curl` a URL to report provisioning success, or even pull down and launch a container before/after.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a product (OpenShift) don't we want to discourage this (modifying ignition). As a product, we may use an underlying technology (from upstream) to accomplish a goal, but not neccarly expose that to the downstream products end-users. (this is how I view ignition - cool upstream tech, that we treat as a black box, inside of the installer)

If we allow this (arbitrary modification of ignition) how will we keep 'ignition' from becoming the next 'ansible' (issue for OpenShift); that makes the infinite number of configuration permutations, impossible for us to comprehend / track; and thus can't ensure a smooth/simple install experience? Is there a way to gate/validate the ignition we get to make sure its safe and does not conflict with our install processes, befor the installer starts?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have to support appending to the openshift-installer generated Ignition today for machine-specific configuration like /etc/hostname and networking etc.

If we allow this (arbitrary modification of ignition) how will we keep 'ignition' from becoming the next 'ansible' (issue for OpenShift); that makes the infinite number of configuration permutations

Today MachineConfig via the MCO already allows executing arbitrary code as root via systemd units - day 1 or day 2. And it's the same thing with Ignition.

Is there a way to gate/validate the ignition we get to make sure its safe and does not conflict with our install processes, befor the installer starts?

I can't really think of a way to do that other than to provide a higher level set of knobs, you could imagine something a bit like https://github.com/coreos/fcct for provisioning time, something like a file:

postInstallURL: http://example.com/provisioning/blah

that openshift-install could perhaps accept and generate the Ignition for the machine install.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the Ignition config described in this paragraph is not the config applied to the installed system. It's a second, independent Ignition config that only applies to the live system which runs the installer itself.


An additional goal is to allow administrators to more easily run RHCOS as a "live" system for *interactive* experiementation and testing. For example, an administrator could run the system from a USB stick to validate the network interface names, etc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another motivation that might be worth mentioning is the new installer isn't written in shell script but in a compiled safe language, which should reduce defect count and make security vulnerabilities harder to slip in.

### Goals

A live ISO and new `coreos-installer` binary are shipped, tested and work in all scenarios supported by the existing CoreOS installer, and contain the new functionality. The legacy installer continues to be provided (for now).

### Non-Goals

Support for Live/diskless nodes joining a cluster.

## Proposal

Add the Live ISO to the RHCOS build process.

The legacy installer continues to be built and tested.

Add a basic (virtualized) test case for the CoreOS installer.

Ship the new `coreos-install` binary at https://mirror.openshift.com and as an RPM in the OpenShift channel.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

coreos-installer


Switch the `e2e-metal` job in Packet to use the new CoreOS installer.

Update the documentation.

### Risks and Mitigations

It might be confusing to have two installers, and it will be an ongoing maintenance burden for the RHCOS team.

## Design Details

### Test Plan

- A basic virtualized kola test
- Convert e2e-metal Packet job

### Graduation Criteria


#### Examples

### Upgrade / Downgrade Strategy

It may be problematic for some customers to adjust their PXE or other automation setup to handle both new and old cases.

## Implementation History

Major milestones in the life cycle of a proposal should be tracked in `Implementation
History`.

## Drawbacks

If we have to carry forward the old CoreOS installer for a significant amount of time, maintenance will be a bit of a burden.

## Alternatives

Keep the existing CoreOS installer and add tweaks to it to report provisioning success, etc. This would quickly approach the general case though that the new Live CoreOS installer handles.