Skip to content
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

Jump to bottom

Docs: scrub bodhi-updates references #1738

Merged
merged 1 commit into from
May 22, 2024
Merged

Docs: scrub bodhi-updates references #1738

Show file tree
Hide file tree
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
12 changes: 4 additions & 8 deletions Design.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:

Expand All @@ -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
Expand Down Expand Up @@ -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).
Expand Down Expand Up @@ -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:

Expand Down Expand Up @@ -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`.

Expand All @@ -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.
8 changes: 2 additions & 6 deletions stream-tooling.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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
Expand All @@ -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.

Expand All @@ -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**

Expand Down
Loading