keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

README.md: Add a "why" section, update background.md

Browse Source 
Point at FCOS and not Project Atomic.  Add an inline "Why"
section since people will want to know that right away.

(An great thing about Github is the prevalence it gives to `README.md`;
 projects should use that as an "elevator pitch")

Drop outdated bits in `background.md`.

Closes: #1895
Approved by: jlebon
This commit is contained in:
Colin Walters 2019-09-04 12:29:17 +00:00 committed by Atomic Bot
parent 3d6b33b6d4
commit 80fd2e883b
2 changed files with 22 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
README.md
View File

@ -33,19 +33,32 @@ For more information, see the online manual: [Read The Docs (rpm-ostree)](https:
- Transactional, background image-based (versioned/checksummed) upgrades - Transactional, background image-based (versioned/checksummed) upgrades
- OS rollback without affecting user data (`/usr` but not `/etc`, `/var`) via libostree - OS rollback without affecting user data (`/usr` but not `/etc`, `/var`) via libostree
- Client-side package layering (and overrides) - Client-side package layering (and overrides)
- Easily make your own: `rpm-ostree compose tree` - Easily make your own: `rpm-ostree compose tree` and [CoreOS Assembler](https://github.com/coreos/coreos-assembler)
Projects using rpm-ostree Projects using rpm-ostree
-------------------------- --------------------------
[Project Atomic](http://www.projectatomic.io/) is an umbrella project for The OSTree project is independent of distributions and agnostic to how content
delivering upstream container technologies and combined with a minimized, is delivered and managed; it's used today by e.g. Debian, Fedora, and OpenEmbedded
atomically upgradable host system to Fedora, Red Hat Enterprise Linux, and CentOS. derived systems among others. There are some examples in the [OSTree github](https://github.com/ostreedev/ostree).
rpm-ostree is the underlying technology for host updates. The headlining project In contrast, rpm-ostree is intended to be tightly integrated with the Fedora
is "Atomic Host", which is a server variant oriented towards running Linux ecosystem. Today it is the underlying update mechanism of [Fedora CoreOS](https://getfedora.org/coreos/)
containers using e.g. Kubernetes. However, there is now also a Workstation as well as its derivative RHEL CoreOS. It is also used by [Fedora IoT](https://iot.fedoraproject.org/)
variant, showing the full generality of the rpm-ostree model. and [Fedora Silverblue](https://silverblue.fedoraproject.org/).
Originally, it was productized as part of [Project Atomic](http://www.projectatomic.io/).
Why?
---
Package systems such as apt and yum are highly prevalent in Linux-based operating systems. The core premise of rpm-ostree is that image-based updates should be the default. This provides a high degree of predictability and resiliency. However, where rpm-ostree is fairly unique in the ecosystem is supporting client-side package layering and overrides; deeply integrating RPM as an (optional) layer on top of OSTree.
A good way to think of package layering is recasting RPMs as "operating system extensions", similar to how browser extensions work (although before those were sandboxed). One can use package layering for components not easily containerized, such as PAM modules, custom shells, etc.
Further, one can easily use `rpm-ostree override replace` to override the kernel or userspace components with the very same RPMs shipped to traditional systems. The Fedora project for example continues to only have one kernel build.
Layering and overrides are still built on top of the default OSTree engine - installing and updating client-side packages constructs a new filesystem root, it does not by default affect your booted root. This preserves the "image" nature of the system.
Manual Manual
------ ------

26
docs/manual/background.md
View File

@ -16,7 +16,7 @@ to fall cleanly into one of two camps: package-based or image-based.
* + Ensures all users are running a known state * + Ensures all users are running a known state
* + Rollback supported * + Rollback supported
* + Can achieve efficient security via things like [dm-verity](http://lwn.net/Articles/459420/) * + Easier to verify system integrity
* - Many image systems have a read-only `/etc`, and writable partitions elsewhere * - Many image systems have a read-only `/etc`, and writable partitions elsewhere
* - Must reboot for updates * - Must reboot for updates
* - Usually operate at block level, so require fixed partition layout and filesystem * - Usually operate at block level, so require fixed partition layout and filesystem
@ -48,27 +48,3 @@ the server side.
On the other hand, rpm-ostree works on top of any Unix filesystem. It On the other hand, rpm-ostree works on top of any Unix filesystem. It
will not interfere with any filesystem or block-level snapshots or will not interfere with any filesystem or block-level snapshots or
backups such as LVM or BTRFS. backups such as LVM or BTRFS.
## Who should use this?
Currently, `rpm-ostree` operates on a read-only mode on installed
systems; it is not possible to add or remove anything on the client
system's `/usr`. If this matches your deployment scenario, rpm-ostree
is a good choice. Classic examples of this are fixed purpose server
farms, "corporate standard build" laptop/desktops, and embedded
devices.
Of course, one can pair it with a dynamic application mechanism such
as [Docker](https://www.docker.com/), and have a reliable base, with a
flexible application tool. This is the rationale behind
[Project Atomic](http://www.projectatomic.io/).
Container technology is flexible enough for "privileged" containers to
affect the host. For example, using the `atomic` command, one can
`atomic run centos/tools` and have a flexible shell with access to
`/host`.
## Is it worth supporting composes both on client and server?
In short, our belief is yes. Long term, rpm-ostree offers a potential
unified tooling via package layering.