From aafaf9f5c9aa7b438960c4fe3336329c4893c304 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Fri, 17 Jan 2014 22:06:25 -0500 Subject: [PATCH] fedostree/web: Lots of wordsmithing for homepage --- fedostree/web/partials/home.html | 99 +++++++++++++++++++++++- fedostree/web/partials/installation.html | 10 +-- 2 files changed, 100 insertions(+), 9 deletions(-) diff --git a/fedostree/web/partials/home.html b/fedostree/web/partials/home.html index 7de0e34d..fa932aeb 100644 --- a/fedostree/web/partials/home.html +++ b/fedostree/web/partials/home.html @@ -3,10 +3,101 @@

An instance of rpm-ostree for Fedora. This project takes multiple RPM package sets from - Fedora, assembles them on the build server side, and stores - these trees in an OSTree repository. Client systems can them - atomically upgrade and switch between these trees. + Fedora, assembles them on the build server side, and stores these + trees in + an OSTree + repository. Client systems can them atomically upgrade and switch + between these trees.

-

Installation

+

Trying it out

See installation.

+

Background

+

Fedora today is an extremely flexible system. One can find + Fedora builds running on everything from hobbyist ARM devices, + to workstations, to testing servers. +

+

This flexibility derives primarily from the fact that from a + technological point of view, Fedora is a collection of packages. + While pre-assembled "deliverables" such as the Live CDs are + distributed by the project, they are only a transitory state. As + soon as they are installed, upgrading involves having a package + manager the dynamically reassemble the system from newer parts in + the Fedora package collection. +

+

Furthermore, nearly every aspect of the Fedora infrastructure + (and documentation) is structured in terms of packages, from + user-facing tools such as Bugzilla and Bodhi, to developer tools + such as Koji. The announced security updates are based on package + names. +

+

One cannot file a bug against the "default offering" as a whole - + a package must be chosen.

+

In contrast for example, ChromeOS is delivered and updated as an + atomic unit. It's far less flexible, but fulfills a targeted role + clearly well.

+

How OSTree allows a middle ground

+

Fundamentally, package systems are partial filesystem trees - + they are assembled by a package manager into a complete bootable + tree. It's important to emphasize that it is only + these complete trees that users run.

+

OSTree allows an OS distributor to + ship multiple complete bootable filesystem + trees, and furthermore, client machines can atomically switch between + these on the client side.

+

This allows a middle ground between the two extremes of a + combinatorial explosion of packages, and a singular OS.

+

For example, these are some of the trees the current prototype generates: +

+

+

Initial goals

+

The first goal of this project is to be an additional + deployment option built in the Fedora infrastructure. In this + phase, developers and testers can use OSTree to replicate and + atomically transition between the pre-assembled trees produced by + this build server. +

+

In this phase, no common mechanism for additional software + installation is provided. That said, individual trees can do so; + for example server/docker-io tree can use Docker to + install and run server container applications independent of + OSTree. +

+

This phase does include basic integration testing on the build + server side, which will be a major benefit to the Fedora project + and its downstreams.

+

Development area: OSTree Layering

+

This phase would be allowing "layering" of trees. For example, + if one installs the base/minimal tree, one could imagine + taking the strace package, and computing a new + filesystem tree which is the union of the two.

+

While plain standalone ELF executables would work with no + modification, a generalization of this kind of dynamic layering + implies a higher level above OSTree that is aware of things + like ldconfig and gtk-update-icon-cache and how + to trigger them when layers are combined.

+

Conceptually, this is a step back towards combinatorics. For example, + if libvirt is a layer that could be applied on top of the base server + layer as well as the workstation layer, then there would need to be + some notion of dependencies. +

+

Development area: Local package assembly

+

There is absolutely no reason one could not just use the package + manager on the client side to download and assemble packages - + but rather than operating live on your current root, OSTree + allows setting up the chosen tree for the next boot + atomically.

+

The problem is making this sort of thing efficient and scalable; + it would require careful integration of the local OSTree repository + and the package manager caching to operate at a speed comparable to + traditional package management. +

diff --git a/fedostree/web/partials/installation.html b/fedostree/web/partials/installation.html index 536ae380..e304235a 100644 --- a/fedostree/web/partials/installation.html +++ b/fedostree/web/partials/installation.html @@ -25,12 +25,12 @@

At this point, we have only initialized configuration. Let's start by downloading the "minimal" install (just @core):

-	ostree pull fedostree fedostree/20/minimal-x86_64
+	ostree pull fedostree fedostree/20/x86_64/base/minimal

This step extracts the root filesystem, and updates the bootloader configuration:

-	ostree admin deploy --os=fedostree fedostree/20/minimal-x86_64
+	ostree admin deploy --os=fedostree fedostree/20/x86_64/base/minimal

We need to do some initial setup before we actually boot the system. Copy in the storage configuration:

@@ -74,15 +74,15 @@ different complete bootable filesystem trees. Let's now try the standard-docker-io tree:

-	ostree pull fedostree fedostree/20/standard-docker-io-x86_64
+	ostree pull fedostree fedostree/20/x86_64/server/docker-io
-

If you look at the fedostree-make-trees script +

If you look at the products.json script you can see this tree contains @core, @standard, and finally docker-io.

Like above, let's now deploy it:

-	ostree admin deploy --os=fedostree fedostree/20/standard-docker-io-x86_64
+	ostree admin deploy --os=fedostree fedostree/20/x86_64/server/docker-io
 	systemctl reboot