Merge pull request #73 from cgwalters/fix-docs

A few docs fixes
This commit is contained in:
Colin Walters 2023-11-27 16:40:38 -05:00 committed by GitHub
commit 503e087502
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 43 additions and 57 deletions

View File

@ -1,13 +0,0 @@
---
nav_order: 2
---
# Relationship with CoreOS
The CoreOS Container Linux project was very successful, spawning multiple projects
and derivatives that continue to see widespread use today.
An aim of this project is to share code and logic with Fedora CoreOS and its derivatives,
such as Red Hat Enterprise Linux CoreOS. At the current time, these systems continue
to exist and success for this project will include sharing as much code as possible
with them.

View File

@ -1,3 +1,7 @@
---
nav_order: 1
---
# Goals
This project's toplevel goal is to maintain default definitions for
@ -41,31 +45,6 @@ For more information, see [the dev repository](https://github.com/centos/centos-
See [install.md](./install.md).
## Differences from Fedora CoreOS
Fedora CoreOS today is not small; there are multiple reasons for this, but
primarily because it was created in a pre-bootable-container time. Not everyone
wants e.g. moby-engine.
But going beyond size, the images produced by this project will focus
on a container-native flow. We will ship a (container) image that does not
include Ignition for example.
## Differences from RHEL CoreOS
We sometimes say that RHEL CoreOS
[has FCOS as an upstream](https://github.com/openshift/os/blob/master/docs/faq.md#q-what-is-coreos)
but this is only kind of true; RHEL CoreOS includes a subset of FCOS content,
and is lifecycled with OCP.
An explicit goal of this project is to produce bootable container images
that can be used as *base images* for RHEL CoreOS; for more on this, see e.g.
<https://github.com/openshift/os/issues/799>
## Differences from RHEL for Edge
It is an explicit goal that CentOS boot also becomes a "base input" to RHEL for Edge.
## Understanding "tiers"
There is a "tier-0" image, but it is not yet being automatically built. The "tier-0"

View File

@ -4,29 +4,16 @@ nav_order: 2
# Trying out development builds
## No default user accounts
The default images produced do *not* include any default passwords or SSH keys.
There is a `root` user present, but its password is locked.
## Using fedora-bootc-cloud via KVM
This repository defines a cloud-agnostic base image. However, many
people who just want to "try things out" will find it easiest to start
Many people who just want to "try things out" will find it easiest to start
with [the cloud image](https://github.com/CentOS/centos-bootc-layered/tree/main/fedora-bootc-cloud).
## Operating system state (users, ssh keys)
It's absolutely crucial to understand that the container image *is* the
operating system content. Notably the default `tier-1` image
[does not include cloud-init](cloud-agents.md) or Ignition or any default
recommended mechanism for provisioning user accountson its own.
Commonly then you will want to build your own container image derived from e.g.
`quay.io/centos-bootc/fedora-bootc:eln` that adds a login mechanism. For
example, you could
[add cloud-init](https://gitlab.com/CentOS/cloud/sagano-examples/-/blob/main/cloud-init-base/Containerfile).
However, it's also possible to embed SSH login configuration in the image, or
configure any login mechanism you desire in general! For example, you could set
up a VPN configuration in your operating system and ensure logins are only
possible over the VPN, etc.
## Installation using Anaconda
Tools like

33
docs/related.md Normal file
View File

@ -0,0 +1,33 @@
---
nav_order: 4
---
# Relationship with other projects
## Fedora CoreOS
The primary focus of Fedora CoreOS is on being a "golden image" that
can be configured via Ignition to run containers. In the Fedora CoreOS
model, the OS is "lifecycled" separately from the workload and configuration.
This project is explicitly designed to be derived from via container
tooling, not Ignition. While we will support a "just run the golden image" flow,
ading and customizing the base image with extra packages and content is the expected
norm. An important corrollary to this is that OS updates are "lifecycled" with the
workload and configuration.
## RHEL CoreOS
We sometimes say that RHEL CoreOS
[has FCOS as an upstream](https://github.com/openshift/os/blob/master/docs/faq.md#q-what-is-coreos)
but this is only kind of true; RHEL CoreOS includes a subset of FCOS content,
and is lifecycled with OCP.
An explicit goal of this project is to produce bootable container images
lifecycled with the base OS, that can be used as *base images* for RHEL CoreOS.
For more on this, see e.g.
<https://github.com/openshift/os/issues/799>
## RHEL for Edge
It is an explicit goal that CentOS boot also becomes a "base input" to RHEL for Edge.