diff --git a/Design.md b/Design.md index 71add3d..e9ec75c 100644 --- a/Design.md +++ b/Design.md @@ -18,7 +18,7 @@ conclusion should be summarized here with a link to the issue. ## OSTree Delivery Format -- Originally discussed in issue [#23](https://github.com/coreos/fedora-coreos-tracker/issues/23). +- Originally discussed in issue [#23](https://github.com/coreos/fedora-coreos-tracker/issues/23). ### Summary: @@ -29,7 +29,7 @@ end user systems: repo) on a server and fetched via HTTP requests. - rojig: uses a special rojig RPM and re-assembles OSTree commit from RPMs already on mirrors. -- OCI: OSTree commits are packaged up in OCI container images and delivered +- OCI: OSTree commits are packaged up in OCI container images and delivered via a container registry. Currently the plan in Fedora CoreOS is to deliver content via a plain @@ -44,7 +44,7 @@ proves useful or necessary. Fedora CoreOS will have several refs for use on production machines. At any given time, each ref will be downstream of a particular Fedora branch, and will consist of a snapshot of Fedora packages plus occasionally a backported fix. -- `testing`: Periodic snapshot of the current Fedora release plus Bodhi `updates`. +- `testing`: Periodic snapshot of the current Fedora release. - `stable`: Promotion of a `testing` release, including any needed fixes. - `next`: The `next` stream represents the future. It will often be used to experiment with new features and also test out rebases of our platform on top of the next major version of Fedora. See [Major Fedora Version Rebases](#major-fedora-version-rebases) for more info. @@ -102,7 +102,7 @@ Because production refs are unversioned, users will seamlessly upgrade between F ## Disk Layout -- Originally discussed in issue [#18](https://github.com/coreos/fedora-coreos-tracker/issues/18). +- Originally discussed in issue [#18](https://github.com/coreos/fedora-coreos-tracker/issues/18). See also [dustymabe's comment](https://github.com/coreos/fedora-coreos-tracker/issues/18#issuecomment-409668929) summarizing the discussion in the FCOS meeting. - Filesystem details were discussed in [#33](https://github.com/coreos/fedora-coreos-tracker/issues/33). @@ -228,7 +228,7 @@ Originally discussed in [#71](https://github.com/coreos/fedora-coreos-tracker/is Originally discussed in [#68](https://github.com/coreos/fedora-coreos-tracker/issues/68). - OpenStack environments do not require a cloud agent -- We will provide any base level of functionality with ignition and coreos-metadata +- We will provide any base level of functionality with ignition and coreos-metadata ### Packet: @@ -345,8 +345,6 @@ next-devel | 10 testing-devel | 20 rawhide | 91 branched | 92 -bodhi-updates-testing | 93 -bodhi-updates | 94 For developer builds (those not produced by the official pipeline), Z is always `dev`. @@ -365,8 +363,6 @@ next-devel | 31.20191018.10.10 | 11th build of the day testing-devel | 31.20191018.20.0 | rawhide | 33.20191018.91.0 | F33-based, first build of the day branched | 32.20191018.92.0 | -bodhi-updates-testing | 31.20191018.93.0 | -bodhi-updates | 31.20191018.94.0 | (any developer build) | 31.20191018.dev.2 | Third build of the day We are not committing to this version scheme indefinitely, and may change it in future if it proves unworkable. A new Fedora major release (X bump) would be a good time to make such a change. We don't intend Fedora CoreOS version numbers to be parsed by machine; they're meant to help humans quickly determine the salient properties of a release. diff --git a/stream-tooling.md b/stream-tooling.md index c0e1a06..f8455b8 100644 --- a/stream-tooling.md +++ b/stream-tooling.md @@ -13,8 +13,6 @@ FCOS will have multiple streams: | Development | next-devel | annex | | Mechanical | rawhide | annex | | Mechanical | branched | annex | -| Mechanical | bodhi-updates | annex | -| Mechanical | bodhi-updates-testing | annex | Development and mechanical streams are subject to change. @@ -32,8 +30,6 @@ We need a way to both (1) fix the content set for a particular stream release, a **Mechanical** streams are not curated; they're automated nightly snapshots of the underlying repos. They source their RPMs from the regular Fedora repos (using 30 here to mean `$currentrelease`): 1. **rawhide** <- f32 2. **branched** <- f31 when a branch exists, otherwise tracks **rawhide** -3. **bodhi-updates** <- f30-stable + f30-updates -4. **bodhi-updates-testing** <- f30-stable + f30-updates + f30-updates-testing **Production** streams are intended for production use. They source their RPMs from a _single_ Koji tag, `coreos-pool`, from which we create a yum repo: 1. **next** <- coreos-pool @@ -52,7 +48,7 @@ There is also a second Koji tag, `coreos-release`, for packages which have been We maintain a git repository containing the rpm-ostree treefile and lockfiles. This could be [fedora-coreos-config](https://github.com/coreos/fedora-coreos-config). We have one branch for each stream, and no main branch. -For the mechanical streams, a nightly job will run the compose from the corresponding yum repos and SCM refs. This job will output a lockfile for each CPU architecture. Those lockfiles will be committed to Git to preserve a record of the build's contents, and the builds will be pushed to the corresponding ostree refs. The {bodhi-updates, branched} lockfile will also be PR'd to the {testing-devel, next-devel} branch, the latter only during the part of the cycle where next-devel is maintained. We want to keep the development branches ready to release, so those PRs are not merged unless green. +For the mechanical streams, a nightly job will run the compose from the corresponding yum repos and SCM refs. This job will output a lockfile for each CPU architecture. Those lockfiles will be committed to Git to preserve a record of the build's contents, and the builds will be pushed to the corresponding ostree refs. The branched lockfile will also be PR'd to the {testing-devel, next-devel} branch, the latter only during the part of the cycle where next-devel is maintained. We want to keep the development branches ready to release, so those PRs are not merged unless green. The lockfiles produced from the automatic snapshot will never be hand-modified, and in the next/testing/stable branches will never be modified at all except during promotions. Instead, pins (to older NEVRAs) and updates (to newer ones) will be hand-maintained in the Git branches in a separate lockfile that overrides the autogenerated ones. These overrides will be the major distinction between the mechanical refs and the "curated" (development/production) refs. Each curated branch will have one override file, which can carry both CPU-architecture-independent and architecture-specific overrides. @@ -74,7 +70,7 @@ Update the development treefile as usual. On the next bot push, the lockfile wil To focus development effort, there will be one base treefile shared across all branches, whose canonical copy will live in the testing-devel branch. Changes will automatically be mirrored to next-devel and to the mechanical branches. To address divergence across Fedora releases, each branch will also have an overlay treefile (possibly empty): -- **testing-devel** -> automatically mirrored to bodhi-updates and bodhi-updates-testing +- **testing-devel** - **next-devel** -> automatically mirrored to branched - **rawhide**