├── .github ├── ISSUE_TEMPLATE │ ├── bug-report.yml │ ├── enhancement.yml │ ├── implementing-new-emerging-platform.md │ ├── implementing-new-platform.md │ ├── new-feature.md │ ├── new-package.yml │ ├── new-platform.yml │ ├── rebase.md │ └── test-week.md └── workflows │ └── checks.yml ├── Design.md ├── PRD.txt ├── README.md ├── RELEASES.md ├── docs ├── 20210204_fcos_official_edition.md ├── 20210204_growing_fcos_community.md ├── ci-and-builds.md ├── fedora-coreos-kernel-bisect.md ├── fedora-coreos-systemd-bisect.md └── testing-project-documentation-changes.md ├── internals ├── README-initramfs.md └── README-internals.md ├── meeting-people.txt ├── metadata ├── README.md ├── release-index │ ├── fcos-release-index-schema.json │ ├── sample.json │ └── specifications.md ├── release │ └── sample.json ├── stream │ ├── rationale.yaml │ └── sample.json └── updates │ ├── fcos-updates-schema.json │ ├── sample.json │ └── specifications.md ├── metrics ├── README.md └── fcos-sqlitevis.json └── stream-tooling.md /.github/ISSUE_TEMPLATE/bug-report.yml: -------------------------------------------------------------------------------- 1 | name: Report a bug 2 | description: Report an issue with Fedora CoreOS 3 | labels: ["kind/bug"] 4 | assignees: [] 5 | body: 6 | - type: textarea 7 | id: bug-description 8 | attributes: 9 | label: Describe the bug 10 | description: A clear and concise description of what the bug is. 11 | placeholder: I'm using foo on bar and it fails with foobar. 12 | validations: 13 | required: true 14 | 15 | - type: textarea 16 | id: bug-reproduction 17 | attributes: 18 | label: Reproduction steps 19 | description: Steps to reproduce the behavior. 20 | placeholder: | 21 | 1. 22 | 2. 23 | 3. 24 | validations: 25 | required: true 26 | 27 | - type: textarea 28 | id: bug-expected 29 | attributes: 30 | label: Expected behavior 31 | description: A clear and concise description of what you expected to happen. 32 | placeholder: Foo should succeed without errors. 33 | validations: 34 | required: true 35 | 36 | - type: textarea 37 | id: bug-actual 38 | attributes: 39 | label: Actual behavior 40 | description: A clear and concise description of what actually happened. 41 | placeholder: Foo failed with ... 42 | validations: 43 | required: true 44 | 45 | - type: textarea 46 | id: bug-system 47 | attributes: 48 | label: System details 49 | description: Version (`rpm-ostree status -b`) and platform (Bare Metal/QEMU/AWS/GCP/etc.) where you've seen the issue. 50 | placeholder: | 51 | - Bare Metal/QEMU/AWS/GCP/etc. 52 | - Fedora CoreOS version 53 | validations: 54 | required: true 55 | 56 | - type: textarea 57 | id: bug-config 58 | attributes: 59 | label: Butane or Ignition config 60 | description: The Butane config or Ignition config used to provision your system. Be sure to sanitize any private data. If not using Butane to generate your Ignition config, ensure the Ignition config passes validation using [ignition-validate](https://coreos.github.io/ignition/getting-started/#config-validation). 61 | # Might be Butane YAML or Ignition JSON, which is upward-compatible 62 | # with YAML 63 | render: yaml 64 | validations: 65 | required: false 66 | 67 | - type: textarea 68 | id: bug-additional 69 | attributes: 70 | label: Additional information 71 | description: Add any other information about the problem here. 72 | validations: 73 | required: false 74 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/enhancement.yml: -------------------------------------------------------------------------------- 1 | name: Request an enhancement 2 | description: Request a new feature in Fedora CoreOS 3 | labels: ["kind/enhancement"] 4 | assignees: [] 5 | body: 6 | - type: textarea 7 | id: enhancement-description 8 | attributes: 9 | label: Describe the enhancement 10 | description: A clear and concise description of the desired feature. 11 | placeholder: I want to use foo with bar on Fedora CoreOS. 12 | validations: 13 | required: true 14 | 15 | - type: textarea 16 | id: enhancement-system 17 | attributes: 18 | label: System details 19 | description: Platform (Bare Metal/QEMU/AWS/GCP/etc.) where you'd want to see this feature. Version you've tried that does not have it. 20 | placeholder: | 21 | - Bare Metal/QEMU/AWS/GCP/etc. 22 | - Fedora CoreOS version 23 | validations: 24 | required: false 25 | 26 | - type: textarea 27 | id: enhancement-additional 28 | attributes: 29 | label: Additional information 30 | description: Add any other information about the problem here. 31 | validations: 32 | required: false 33 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/implementing-new-emerging-platform.md: -------------------------------------------------------------------------------- 1 | # Implementing a new emerging platform 2 | 3 | This template is a simplified version of the 4 | [full template](https://github.com/coreos/fedora-coreos-tracker/blob/main/.github/ISSUE_TEMPLATE/implementing-new-platform.md) 5 | that only includes what is strictly needed to get initial support for a new 6 | platform in Fedora CoreOS. This simplified version notably does not include the 7 | steps needed to add new boot images to the release process. 8 | 9 | Platforms added via this process are labelled "emerging" and users will have to 10 | get boot images for them by converting existing images in the right format and 11 | changing the `ignition.platform.id=` command line parameter. 12 | 13 | This process will be documented using `guestfish` as an example. 14 | 15 | ## During Development 16 | 17 | Create PRs addressing the following: 18 | 19 | - [ ] [Ignition](https://github.com/coreos/ignition/) ([example PR](https://github.com/coreos/ignition/pull/918)) 20 | - [ ] Add userdata fetch 21 | - [ ] If the platform supports it (unlikely), add userdata deletion 22 | - [ ] [Afterburn](https://github.com/coreos/afterburn/) ([example PR](https://github.com/coreos/afterburn/pull/451)) 23 | - [ ] (Cloud Only) Add relevant attributes 24 | - [ ] (Cloud Only) Add SSH key support if available 25 | - [ ] (Cloud Only) Add hostname support if available 26 | - [ ] (Cloud Only) Add check-in if needed (unlikely) 27 | - [ ] [fedora-coreos-docs](https://github.com/coreos/fedora-coreos-docs) ([example PR](https://github.com/coreos/fedora-coreos-docs/pull/377)) 28 | - [ ] Add a `provisioning-.adoc` that walks through how to setup the new platform 29 | - [ ] Add an entry in the `modules/ROOT/nav.adoc` that points to new documentation 30 | - [ ] (Optional but recommended) Add support for the platform to [kola](https://github.com/coreos/coreos-assembler) to simplify testing 31 | - Create or ask for a new upstream releases for: 32 | - [ ] Ignition 33 | - [ ] Afterburn 34 | - Wait for new images with updated Ignition and Afterburn to reach stable then 35 | merge documentation with `guestfish` commands: 36 | - [ ] fedora-coreos-docs 37 | 38 | ## At Release 39 | 40 | There are no "At Release" steps as we do not produce new boot images for 41 | emerging platforms/ 42 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/implementing-new-platform.md: -------------------------------------------------------------------------------- 1 | # Implementing a new supported platform 2 | 3 | ## During Development 4 | 5 | Create PRs addressing the following: 6 | 7 | - [ ] [Ignition](https://github.com/coreos/ignition/) ([example PR](https://github.com/coreos/ignition/pull/918)) 8 | - [ ] Add userdata fetch 9 | - [ ] If the platform supports it (unlikely), add userdata deletion 10 | - [ ] [Afterburn](https://github.com/coreos/afterburn/) ([example PR](https://github.com/coreos/afterburn/pull/451)) 11 | - [ ] (Cloud Only) Add relevant attributes 12 | - [ ] (Cloud Only) Add SSH key support if available 13 | - [ ] (Cloud Only) Add hostname support if available 14 | - [ ] (Cloud Only) Add check-in if needed (unlikely) 15 | - [ ] [stream-metadata-go](https://github.com/coreos/stream-metadata-go) ([example PR](https://github.com/coreos/stream-metadata-go/pull/45/)) 16 | - [ ] Add platform to the `Media` struct in `release/release.go` 17 | - [ ] Add supporting code for new platform to `toStreamArch` func in `release/translate.go` 18 | - [ ] (Cloud Only) Cloud Images need to have an `Images` field 19 | - [ ] (Cloud Only) [stream-metadata-rust](https://github.com/coreos/stream-metadata-rust/) ([example PR](https://github.com/coreos/stream-metadata-rust/pull/16)) 20 | - [ ] [fedora-coreos-tracker](https://github.com/coreos/fedora-coreos-tracker/) ([example PR](https://github.com/coreos/fedora-coreos-tracker/pull/1213)) 21 | - [ ] Update the metadata for the new platform 22 | - [ ] [coreos-assembler](https://github.com/coreos/coreos-assembler) ([example PR](https://github.com/coreos/coreos-assembler/pull/2489)) 23 | - [ ] Updated `cmd-generate-release-meta` 24 | - [ ] `cosa osbuild ` works 25 | - [ ] [fedora-coreos-config](https://github.com/coreos/fedora-coreos-config/) 26 | - [ ] Add a stanza to `platforms.yaml` if the system should use a serial console, or both serial and graphical consoles 27 | - [ ] [fedora-websites-3.0](https://gitlab.com/fedora/websites-apps/fedora-websites/fedora-websites-3.0/) 28 | - [ ] Add friendly name for platform to `components/utilities/FpDownloadItem.vue` 29 | - [ ] Add artifact to `pages/coreos/download.vue` 30 | - [ ] Possibly add logo to `content/editions/coreos/home.yml` 31 | - [ ] [fedora-coreos-browser](https://github.com/coreos/fedora-coreos-browser) ([example PR](https://github.com/coreos/fedora-coreos-browser/pull/35)) 32 | - [ ] Add a list element for new platform in `browser/index.html` 33 | - [ ] [build pipeline](https://github.com/coreos/fedora-coreos-pipeline) ([example PR](https://github.com/coreos/fedora-coreos-pipeline/pull/815)) 34 | - [ ] Add platform to the list found in `config.yaml` for building the new artifact 35 | - [ ] [fedora-coreos-docs](https://github.com/coreos/fedora-coreos-docs) ([example PR](https://github.com/coreos/fedora-coreos-docs/pull/377)) 36 | - [ ] Add a `provisioning-.adoc` that walks through how to setup the new platform 37 | - [ ] Add an entry in the `modules/ROOT/nav.adoc` that points to new documentation 38 | 39 | ## At Release 40 | 41 | 1. Merge upstream changes and put out a release: 42 | - [ ] Ignition 43 | - [ ] Afterburn 44 | 1. Merge metadata changes: 45 | - [ ] stream-metadata-go 46 | - [ ] stream-metadata-rust 47 | - [ ] fedora-coreos-tracker 48 | - [ ] fedora website 49 | - [ ] fedora-coreos-browser 50 | 1. Release updated components 51 | - [ ] Create and follow release checklist for [stream-metadata-go](https://github.com/coreos/stream-metadata-go/blob/main/docs/development.md#release-process) 52 | - [ ] Ensure that Dependabot has PRed stream-metadata-go into fedora-coreos-stream-generator and coreos-assembler. Merge the update PRs. 53 | - This can be triggered manually by navigating to [fedora-coreos-stream-generator's Dependabot](https://github.com/coreos/fedora-coreos-stream-generator/network/updates/) and [coreos-assembler's Dependabot](https://github.com/coreos/coreos-assembler/network/updates) respectively, then clicking "Check for updates". 54 | - This might need to be done a few times, as Dependabot might not pick up tag changes for a few attempts after initial tagging. 55 | - [ ] Create and follow release checklist for [fedora-coreos-stream-generator](https://github.com/coreos/fedora-coreos-stream-generator/blob/main/docs/development.md#release-process) 56 | 1. Merge the following changes: 57 | - [ ] coreos-assembler 58 | 1. Wait for updates made to coreos-assembler to be propagated to latest container 59 | - [ ] Download latest version of coreos-assembler container. Verify platform support functionality. 60 | 1. Merge changes for: 61 | - [ ] Build pipeline 62 | 1. Wait for new images to reach stable then merge documentation. 63 | - [ ] fedora-coreos-docs merged 64 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/new-feature.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Implement a feature 3 | about: Propose a design for a new feature 4 | --- 5 | 6 | # Feature proposal 7 | 8 | ## Description 9 | 10 | 11 | 12 | ## Implementation PRs 13 | 14 | 15 | 16 | ## Did you consider? 17 | 18 | 19 | 20 | - Storage 21 | - [ ] Disk space usage 22 | - [ ] Behavior on 4Kn disks 23 | - [ ] Compatibility with multiple ESPs (Butane `boot_device.mirror`) 24 | - First boot 25 | - [ ] Behavior on first boot vs. second boot 26 | - [ ] initrd networking requirements 27 | - [ ] Reprovisioned systems that reused existing storage devices 28 | - OS update 29 | - [ ] Behavior after an OS rollback 30 | - [ ] Compatibility with old bootloaders 31 | - Architectures 32 | - aarch64 33 | - [ ] Compatibility with non-UEFI boot 34 | - ppc64le 35 | - [ ] Whether new GRUB directives are supported by petitboot 36 | - s390x 37 | - [ ] Endianness issues 38 | - [ ] Need to rerun `zipl` to update kernel or kargs 39 | - [ ] ECKD/MBR lack of partition labels 40 | - [ ] ECKD maximum partition count 41 | - Implementation 42 | - [ ] How interlocking PRs will be ratcheted into repos 43 | 44 | ## Implementation steps 45 | 46 | - [ ] Create tracker ticket with initial design (above) 47 | - [ ] Initial discussion and refinement in the ticket 48 | - [ ] Add `meeting` label 49 | - [ ] Discuss at community meeting 50 | - [ ] Further refinement 51 | - [ ] Post draft [fedora-coreos-docs](https://github.com/coreos/fedora-coreos-docs/) PR, ideally before doing any implementation, to help identify design problems. 52 | - [ ] Update issue description with final proposal and post a comment saying that you did 53 | - [ ] Verify that rough consensus exists 54 | - [ ] Implement. Post PR links in the section above. In the description of each PR, link to this issue and specify the prerequisites for merging. 55 | - [ ] Add kola test(s) for new feature 56 | - [ ] Land implementation PRs, in order 57 | - [ ] Wait for the functionality to reach FCOS stable 58 | - [ ] Land docs PR 59 | - [ ] Remove any ratcheting glue (e.g. workarounds in coreos-assembler) 60 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/new-package.yml: -------------------------------------------------------------------------------- 1 | name: Request a new package 2 | description: Ask for a new package to be added to Fedora CoreOS 3 | title: "New Package Request: " 4 | labels: ["kind/enhancement"] 5 | assignees: [] 6 | body: 7 | - type: markdown 8 | attributes: 9 | value: | 10 | Please try to answer the following questions about the package you are requesting. 11 | 12 | - type: textarea 13 | id: newpackage-dependencies 14 | attributes: 15 | label: What, if any, are the additional dependencies on the package? (i.e. does it pull in Python, Perl, etc) 16 | description: Paste here the output of `rpm-ostree install --dry-run ` from a fresh Fedora CoreOS node. 17 | validations: 18 | required: true 19 | 20 | - type: textarea 21 | id: newpackage-size 22 | attributes: 23 | label: What is the size of the package and its dependencies? 24 | description: Paste here the output of `rpm -qi ` for each package mentioned above. 25 | validations: 26 | required: true 27 | 28 | - type: textarea 29 | id: newpackage-solution 30 | attributes: 31 | label: What problem are you trying to solve with this package? Or what functionality does the package provide? 32 | validations: 33 | required: true 34 | 35 | - type: textarea 36 | id: newpackage-container 37 | attributes: 38 | label: Can the software provided by the package be run from a container? Explain why or why not. 39 | validations: 40 | required: true 41 | 42 | - type: textarea 43 | id: newpackage-debug-container 44 | attributes: 45 | label: Can the tool(s) provided by the package be helpful in debugging container runtime issues? 46 | validations: 47 | required: true 48 | 49 | - type: textarea 50 | id: newpackage-debug-network 51 | attributes: 52 | label: Can the tool(s) provided by the package be helpful in debugging networking issues? 53 | validations: 54 | required: true 55 | 56 | - type: textarea 57 | id: newpackage-day2 58 | attributes: 59 | label: Is it possible to layer the package onto the base OS as a day 2 operation? Explain why or why not. 60 | description: Can the package be installed on first boot or later with `rpm-ostree install `? 61 | validations: 62 | required: true 63 | 64 | - type: textarea 65 | id: newpackage-service 66 | attributes: 67 | label: In the case of packages providing services and binaries, can the packaging be adjusted to just deliver binaries? 68 | validations: 69 | required: true 70 | 71 | - type: textarea 72 | id: newpackage-interpreter 73 | attributes: 74 | label: Can the tool(s) provided by the package be used to do things we’d rather users not be able to do in FCOS? 75 | description: E.g. can it be abused as a Turing complete interpreter? 76 | validations: 77 | required: true 78 | 79 | - type: textarea 80 | id: newpackage- 81 | attributes: 82 | label: Does the software provided by the package have a history of CVEs? 83 | validations: 84 | required: true 85 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/new-platform.yml: -------------------------------------------------------------------------------- 1 | name: Request a new platform 2 | description: Ask for Fedora CoreOS to support a new cloud environment 3 | title: "Platform Request: " 4 | labels: ["area/platforms", "kind/enhancement"] 5 | assignees: [] 6 | body: 7 | - type: markdown 8 | attributes: 9 | value: | 10 | In order to implement support for a new cloud platform in Fedora CoreOS, we need to know several things about the platform. Please try to answer as many questions as you can. 11 | 12 | - type: textarea 13 | id: newplatform-user 14 | attributes: 15 | label: Why is the platform important? Who uses it? 16 | validations: 17 | required: false 18 | 19 | - type: textarea 20 | id: newplatform-name 21 | attributes: 22 | label: What is the official name of the platform? Is there a short name that's commonly used in client API implementations? 23 | validations: 24 | required: false 25 | 26 | - type: textarea 27 | id: newplatform-userdata 28 | attributes: 29 | label: How can the OS retrieve instance userdata? What happens if no userdata is provided? 30 | validations: 31 | required: false 32 | 33 | - type: textarea 34 | id: newplatform-sshkeys 35 | attributes: 36 | label: Does the platform provide a way to configure SSH keys for the instance? How can the OS retrieve them? What happens if none are provided? 37 | validations: 38 | required: false 39 | 40 | - type: textarea 41 | id: newplatform-network 42 | attributes: 43 | label: How can the OS retrieve network configuration? Is DHCP sufficient, or is there some other network-accessible metadata service? 44 | validations: 45 | required: false 46 | 47 | - type: textarea 48 | id: newplatform-hostname 49 | attributes: 50 | label: In particular, how can the OS retrieve the system hostname? 51 | validations: 52 | required: false 53 | 54 | - type: textarea 55 | id: newplatform-console 56 | attributes: 57 | label: Does the platform require the OS to have a specific console configuration? 58 | validations: 59 | required: false 60 | 61 | - type: textarea 62 | id: newplatform-boot-success 63 | attributes: 64 | label: Is there a mechanism for the OS to report to the platform that it has successfully booted? Is the mechanism required? 65 | validations: 66 | required: false 67 | 68 | - type: textarea 69 | id: newplatform-agent 70 | attributes: 71 | label: Does the platform have an agent that runs inside the instance? Is it required? What does it do? What language is it implemented in, and where is the source code repository? 72 | validations: 73 | required: false 74 | 75 | - type: textarea 76 | id: newplatform-image-upload 77 | attributes: 78 | label: How are VM images uploaded to the platform and published to other users? Is there an API? What disk image format is expected? 79 | validations: 80 | required: false 81 | 82 | - type: textarea 83 | id: newplatform-quirks 84 | attributes: 85 | label: Are there any other platform quirks we should know about? 86 | validations: 87 | required: false 88 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/rebase.md: -------------------------------------------------------------------------------- 1 | # Rebase to a new version of Fedora (N) 2 | 3 | ## At previous Fedora major release 4 | 5 | ### Open tickets to track related work for this release 6 | 7 | - [ ] Fedora Changes Considerations ([example](https://github.com/coreos/fedora-coreos-tracker/issues/1222)) 8 | - [ ] Package Additions/Removals ([example](https://github.com/coreos/fedora-coreos-tracker/issues/1221)) 9 | - [ ] Test Week ([template](https://github.com/coreos/fedora-coreos-tracker/issues/new?template=test-week.md&title=tracker:+FN+Test+Week)) 10 | - [ ] Communications Tracker ([example](https://github.com/coreos/fedora-coreos-tracker/issues/1655)) 11 | 12 | ## At Branching 13 | 14 | Branching is when a new stream is "branched" off of `rawhide`. This eventually becomes the next major Fedora (N). 15 | 16 | ### Release engineering changes 17 | 18 | - [ ] Verify that a few tags were created when branching occurred: 19 | 20 | - `f${N+1}-coreos-signing-pending` 21 | - `f${N+1}-coreos-continuous` 22 | 23 | - [ ] Add and tag a package (any package) which is in the stable repos into the continuous tag. This will create the initial yum repo that's used as input for building the COSA container. 24 | 25 | - `koji add-pkg --owner ${FAS_USERNAME} f${N+1}-coreos-continuous $PKG` 26 | - example: `koji add-pkg --owner dustymabe f36-coreos-continuous fedora-release` 27 | - This example uses the [`fedora-release`](https://src.fedoraproject.org/rpms/fedora-release) RPM, but it could be any other. 28 | - `koji tag-build f${N+1}-coreos-continuous $BUILD` 29 | - example: `koji tag-build f36-coreos-continuous fedora-release-36-0.16` 30 | 31 | - [ ] Add the N+1 signing key short hash (usually found [here](https://pagure.io/fedora-infra/ansible/blob/main/f/roles/bodhi2/backend/templates/pungi.rpm.conf.j2)) to the tag info for the coreos-pool tag. The following commands view the current settings and then update the list to the 32/33/34/35 keys. You'll most likely have to get someone from releng to run the second command (`edit-tag`). 32 | - `koji taginfo coreos-pool` 33 | - `koji edit-tag coreos-pool -x tag2distrepo.keys="12c944d0 9570ff31 45719a39 9867c58f"` 34 | 35 | ### coreos-installer changes 36 | 37 | - [ ] Update coreos-installer to know about the signing key used for the future new major version of Fedora (N+1). 38 | - The current set of trusted signing keys is available at https://fedoraproject.org/security/. 39 | - If the Fedora (N+1) signing key isn't available yet at that site, you can also get it from https://src.fedoraproject.org/rpms/fedora-repos/tree/rawhide. 40 | - [ ] Drop the signing key for the obsolete stable release (N-2). 41 | 42 | Example PR: https://github.com/coreos/coreos-installer/pull/1113 43 | 44 | ### Update `rawhide` stream 45 | 46 | - [ ] Update [manifest.yaml](https://github.com/coreos/fedora-coreos-config/blob/rawhide/manifest.yaml) to list N+1 as the releasever ([example PR](https://github.com/coreos/fedora-coreos-config/pull/2855)) 47 | 48 | ### Enable `branched` stream 49 | 50 | - [ ] Update [manifest.yaml](https://github.com/coreos/fedora-coreos-config/blob/branched/manifest.yaml) to list N as the releasever ([example PR](https://github.com/coreos/fedora-coreos-config/pull/2549)) 51 | - [ ] Update [config.yaml](https://github.com/coreos/fedora-coreos-pipeline/blob/main/config.yaml) to un-comment out the `branched` stream definition ([example PR](https://github.com/coreos/fedora-coreos-pipeline/pull/904)) 52 | 53 | ## At Fedora (N) Beta 54 | 55 | ### Update [fedora-coreos-config](https://github.com/coreos/fedora-coreos-config/) `next-devel` 56 | 57 | - [ ] Bump `releasever` in `manifest.yaml` 58 | - [ ] Add the `fedora-candidate-compose` repo in `manifest.yaml` ([example PR](https://github.com/coreos/fedora-coreos-config/pull/2706)) 59 | - [ ] Update the repos in `manifest.yaml` if needed 60 | - [ ] Run `cosa fetch --dry-run --update-lockfile` 61 | - this updates the x86_64 lockfile - the others will get updated when `bump-lockfile` runs. 62 | - in the future we may support [this](https://github.com/coreos/coreos-assembler/issues/3088) in `cosa fetch` directly 63 | - [ ] PR the result 64 | 65 | - [ ] Re-enable `next-devel` if needed ([docs](https://github.com/coreos/fedora-coreos-pipeline/tree/main/next-devel)) 66 | - [ ] Disable `branched` stream since it is no longer needed. 67 | - Update [config.yaml](https://github.com/coreos/fedora-coreos-pipeline/blob/main/config.yaml) to comment out the `branched` stream definition. 68 | 69 | ### Ship rebased `next` 70 | 71 | - [ ] Ship `next` 72 | - [ ] Set a new update barrier for the final release of N-1 on `next`. In the barrier entry set a link to [the docs](https://docs.fedoraproject.org/en-US/fedora-coreos/update-barrier-signing-keys/). See [discussion](https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-1247314065) 73 | 74 | 75 | ## Preparing for Fedora (N) GA 76 | 77 | Do these steps as soon as we have a Go confirmation for GA, usually the Thursday of the week before GA. 78 | 79 | ### Ship a final `next` release 80 | 81 | If the packages in `next-devel` don't exactly match the last `next` release that was done, we need to do a release with the final GA content. This ensures that what we'll promote to `testing` has the exact content in GA (plus version fast-tracks). This usually happens on the Thursday of the announcement of Go. 82 | 83 | - [ ] Ensure final `next` release has GA content 84 | 85 | ### Build rebased `testing` and final `stable` release on N-1 86 | 87 | - [ ] Build `stable`; promote it from the `testing` branch, which should still be on N-1. Don't release it yet (i.e. don't run the `release` job). 88 | - [ ] Build `testing`; promote it from the `next` branch instead of `testing-devel`. Don't release it yet (i.e. don't run the `release` job). 89 | 90 | ### Update [fedora-coreos-config](https://github.com/coreos/fedora-coreos-config/) `testing-devel` 91 | 92 | - [ ] Bump `releasever` in `manifest.yaml` 93 | - [ ] Update the repos in `manifest.yaml` if needed 94 | - [ ] Sync the lockfiles for all arches from `next-devel` 95 | - [ ] Bump the base Fedora version in `ci/buildroot/Dockerfile` 96 | - [ ] Bump the Fedora version for the test containers in `tests/kola/data/commonlib.sh` 97 | - [ ] PR the result 98 | 99 | 100 | ## At Fedora (N) GA 101 | 102 | Do these steps on GA day. 103 | 104 | ### Release rebased `testing` and final `stable` release on N-1 105 | 106 | - [ ] Run the `release` job for the staged `testing` and `stable` builds and start rollout. 107 | - [ ] Set a new update barrier for the final release of N-1 on `testing`. In the barrier entry set a link to [the docs](https://docs.fedoraproject.org/en-US/fedora-coreos/update-barrier-signing-keys/). See [discussion](https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-1247314065) 108 | 109 | ### Disable `next-devel` stream if not needed 110 | 111 | We prefer to disable `next-devel` when there is no difference between `testing-devel` and `next-devel`. This allows us to prevent wasting a bunch of resources (bandwidth, storage, compute) for no reason. After the switch to N if `next-devel` and `testing-devel` are in lockstep, then disable `next-devel`. 112 | 113 | - [ ] Follow the instructions [here](https://github.com/coreos/fedora-coreos-pipeline/tree/main/next-devel) to disable `next-devel` 114 | 115 | ### Switch upstream packages to shipping release binaries from Fedora (N) 116 | 117 | - [ ] Update [repo-templates](https://github.com/coreos/repo-templates) [config.yaml](https://github.com/coreos/repo-templates/blob/main/config.yaml) with the version number and GPG key ID for Fedora (N). 118 | 119 | ### Disable the `fedora-candidate-compose` repo 120 | 121 | - [ ] Remove from the `manifest.yaml` of `next-devel` the `fedora-candidate-compose` repo 122 | 123 | ## After Fedora (N) GA 124 | 125 | ### Ship rebased `stable` 126 | 127 | - [ ] Ship `stable` 128 | - [ ] Set a new update barrier for the final release of N-1 on `stable`. In the barrier entry set a link to [the docs](https://docs.fedoraproject.org/en-US/fedora-coreos/update-barrier-signing-keys/). See [discussion](https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-1247314065) 129 | 130 | ### Untag old packages 131 | 132 | `koji untag` N-2 packages from the pool (at some point we'll have GC in place to do this for us, but for now we must remember to do this manually or otherwise distRepo will fail once the signed packages are GC'ed). For example the following snippet finds all RPMs signed by the Fedora 32 key and untags them. Use this process: 133 | 134 | - [ ] Find the key short hash. Usually found [here](https://pagure.io/fedora-infra/ansible/blob/main/f/roles/bodhi2/backend/templates/pungi.rpm.conf.j2). Then: 135 | 136 | ``` 137 | f32key=12c944d0 138 | key=$f32key 139 | echo > untaglist # create or empty out file 140 | for build in $(koji list-tagged --quiet coreos-pool | cut -f1 -d' '); do 141 | if koji buildinfo $build | grep $key 1>/dev/null; then 142 | echo "Adding $build to untag list" 143 | echo "${build}" >> untaglist 144 | fi 145 | done 146 | ``` 147 | 148 | Now we have a list of builds to untag. But we need a few more sanity checks. 149 | 150 | - [ ] Make sure none of the builds are used in `N` based FCOS. Check by running: 151 | 152 | ``` 153 | f32key=12c944d0 154 | key=$f32key 155 | podman run -it --rm quay.io/fedora/fedora-coreos:testing-devel rpm -qai | grep -B 9 $key 156 | podman rmi quay.io/fedora/fedora-coreos:testing-devel 157 | ``` 158 | 159 | If there are any RPMs signed by the old key they'll need to be investigated. Maybe they shouldn't be used any longer. Or maybe they're still needed. One example of this is the shim RPM where the same build could be used for many Fedora releases. In this case you'll need to untag the RPM from `coreos-pool`, run a `koji distrepo`, which will remove that RPM from the repo metadata, and then re-tag it into the pool. The RPM in the repo will now be signed with a newer signing key. 160 | 161 | 162 | 163 | - [ ] After verifying the list looks good, untag: 164 | 165 | ``` 166 | # use xargs so we don't exhaust bash string limit 167 | cat untaglist | xargs -L50 koji untag-build -v coreos-pool 168 | ``` 169 | 170 | - [ ] Now that untagging is done, give a heads up to rpm-ostree developers that N-2 packages have been untagged and that they may need to update their CI compose tests to freeze on a newer FCOS commit. 171 | 172 | - [ ] Remove the N-2 signing key from the tag info for the coreos-pool tag. The following commands view the current settings and then update the list to the 33/34/35 keys. You'll most likely have to get someone from releng to run the second command (`edit-tag`). 173 | - `koji taginfo coreos-pool` 174 | - `koji edit-tag coreos-pool -x tag2distrepo.keys="9570ff31 45719a39 9867c58f"` 175 | 176 | ### Open ticket for the next Fedora rebase 177 | 178 | - [ ] Create a new ticket from the [rebase template](https://github.com/coreos/fedora-coreos-tracker/issues/new?assignees=&labels=area%2Fplatforms%2C+kind%2Fenhancement&template=rebase.md&title=tracker:+Rebase+onto+Fedora+N) 179 | - label with `FN` label where `N` is the Fedora version. 180 | 181 | 182 | ## Miscellaneous container updates 183 | 184 | These are various containers in use throughout our ecosystem. We should update or open a ticket to track updating them once a new Fedora release is out. If you open a ticket instead of doing the update add a link to the ticket as comment. 185 | 186 | - [ ] Update coreos-assembler or open ticket to update: 187 | - [Dockerfile](https://github.com/coreos/coreos-assembler/blob/main/Dockerfile) 188 | - [Dockerfiles for kola test containers](https://github.com/coreos/coreos-assembler/tree/main/tests/containers) 189 | - [ ] Update coreos-installer 190 | - [Dockerfile](https://github.com/coreos/coreos-installer/blob/main/Dockerfile) 191 | - [ ] Update Ignition 192 | - [Dockerfile.validate](https://github.com/coreos/ignition/blob/main/Dockerfile.validate) 193 | - [ ] Update Butane 194 | - [Dockerfile](https://github.com/coreos/butane/blob/main/Dockerfile) 195 | - [ ] Update fedora-coreos-cincinnati 196 | - [Dockerfile](https://github.com/coreos/fedora-coreos-cincinnati/blob/main/dist/fedora-infra/Dockerfile) 197 | - [ImageStream](https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/coreos-cincinnati/templates/imagestream.yml) 198 | - [BuildConfig](https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/coreos-cincinnati/templates/buildconfig.yml) 199 | - [Git Hash Variables (Optional)](https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/coreos-cincinnati/vars) 200 | - [ ] Update config-bot 201 | - [Dockerfile](https://github.com/coreos/fedora-coreos-releng-automation/blob/main/config-bot/Dockerfile) 202 | - [ ] Update coreos-koji-tagger 203 | - [Dockerfile](https://github.com/coreos/fedora-coreos-releng-automation/blob/main/coreos-koji-tagger/Dockerfile) 204 | - [ImageStream](https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/coreos-koji-tagger/templates/imagestream.yml) 205 | - [BuildConfig](https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/coreos-koji-tagger/templates/buildconfig.yml) 206 | - [ ] Update coreos-ostree-importer 207 | - [Dockerfile](https://github.com/coreos/fedora-coreos-releng-automation/blob/main/coreos-ostree-importer/Dockerfile) 208 | - [ImageStream](https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/coreos-ostree-importer/templates/imagestream.yml) 209 | - [BuildConfig](https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/coreos-ostree-importer/templates/buildconfig.yml) 210 | - [ ] Update fedora-ostree-pruner 211 | - [Dockerfile](https://github.com/coreos/fedora-coreos-releng-automation/blob/main/fedora-ostree-pruner/Dockerfile) 212 | - [ImageStream](https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/fedora-ostree-pruner/templates/imagestream.yml) 213 | - [BuildConfig](https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/fedora-ostree-pruner/templates/buildconfig.yml) 214 | - [ ] Update RHCOS extensions container 215 | - [Dockerfile](https://github.com/openshift/os/blob/master/extensions/Dockerfile) 216 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/test-week.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Schedule a Fedora Test Week 3 | about: Schedule a Fedora Test Week for a new Fedora major release 4 | title: '' 5 | labels: 'community', 'meeting' 6 | assignees: '' 7 | --- 8 | 9 | ## Initial Tasks (to be done at least one week before test week) 10 | 11 | - [ ] Open this ticket in the `fedora-coreos-tracker` repo 12 | - [ ] Open a ticket with [Fedora QA](https://pagure.io/fedora-qa/issues). 13 | - [F36 example](https://pagure.io/fedora-qa/issue/695) 14 | 15 | To be done after the Fedora QA folks have taken action on the QA ticket: 16 | 17 | - [ ] Confirm the Test Day page is created on the Fedora Wiki. 18 | - For example: 19 | - [ ] Confirm the Test Day results app is created. 20 | - For example: 21 | - [ ] Choose a day during the Test Week to host a video session for live debug help 22 | - [ ] Setup a Google Meet or other video conference session 23 | - [ ] Create a HackMD doc for capturing notes during live video session 24 | - [ ] Find volunteers to enumerate new documentation + test cases required for Test Week 25 | - Best done via dedicated video session 26 | - [ ] File an issue on `fedora-coreos-tracker` with TODO items. 27 | - For example: 28 | - [ ] File a ticket requesting a Fedora badge is created 29 | - For example: 30 | 31 | ## Announcing Test Week 32 | 33 | Should be completed after the Initial Tasks are done 34 | 35 | - [ ] Draft an email to announcing the Test Week 36 | - [ ] Include a link to the Fedora Wiki 37 | - [ ] Include a link to the Test Day results app 38 | - [ ] Include a link to `fedora-coreos-tracker` for Test Week 39 | - [ ] Include a link to the video conference 40 | - [ ] Include a link to the HackMD doc 41 | - [ ] Cross-post announcement email to discussion.fedoraproject.org with `#coreos` tag 42 | 43 | - Example format: 44 | 45 | ## During Test Week 46 | 47 | - Monitor `fedora-coreos-tracker` for new issues reported as part of Test Week 48 | - Monitor #fedora-coreos on IRC for new issues reported as part of Test Week 49 | - Ensure there is one or more representatives of Fedora CoreOS team present for live video session 50 | 51 | ## After Test Week 52 | 53 | - [ ] Update `fedora-coreos-tracker` ticket with any issues found 54 | - [ ] Update `fedora-coreos-tracker` ticket with any documentation updates made 55 | - [ ] Review Test Day results app and follow-up on any errors reported, if possible 56 | - [ ] Follow up with the Fedora Badges ticket with Fedora Account System (FAS) usernames that participated in Test Week 57 | -------------------------------------------------------------------------------- /.github/workflows/checks.yml: -------------------------------------------------------------------------------- 1 | --- 2 | name: Checks 3 | 4 | on: 5 | push: 6 | branches: [main] 7 | pull_request: 8 | branches: [main] 9 | 10 | jobs: 11 | checks: 12 | name: Checks 13 | runs-on: ubuntu-latest 14 | steps: 15 | - name: Check out repository 16 | uses: actions/checkout@v3 17 | - name: Verify meeting-people.txt is sorted 18 | run: awk '!/^$/ {if (name) print} /^exit 0$/ { name = 1 }' meeting-people.txt | sort -c 19 | -------------------------------------------------------------------------------- /Design.md: -------------------------------------------------------------------------------- 1 | # Design Document 2 | 3 | This document captures the design decisions made after discussion in issues. When a design issue is closed, the 4 | conclusion should be summarized here with a link to the issue. 5 | 6 | - [OSTree Delivery Format](#ostree-delivery-format) 7 | - [Release Streams](#release-streams) 8 | - [Disk Layout](#disk-layout) 9 | - [Approach towards shipping Python](#approach-towards-shipping-Python) 10 | - [Identification in `/etc/os-release`](#identification-in-etcos-release) 11 | - [Firewall management](#firewall-management) 12 | - [Cloud Agents](#cloud-agents) 13 | - [Supported Ignition Versions](#supported-ignition-versions) 14 | - [Configuration Language and Transpiler](#configuration-language-and-transpiler) 15 | - [Security policies](#security-policies) 16 | - [Bucket layout](#bucket-layout) 17 | - [Version numbers](#version-numbers) 18 | 19 | ## OSTree Delivery Format 20 | 21 | - Originally discussed in issue [#23](https://github.com/coreos/fedora-coreos-tracker/issues/23). 22 | 23 | ### Summary: 24 | 25 | There are three proposed delivery models for delivering content to 26 | end user systems: 27 | 28 | - OSTree Repo: OSTree commits are stored in an OSTree repo (like a git 29 | repo) on a server and fetched via HTTP requests. 30 | - rojig: uses a special rojig RPM and re-assembles OSTree commit from RPMs 31 | already on mirrors. 32 | - OCI: OSTree commits are packaged up in OCI container images and delivered 33 | via a container registry. 34 | 35 | Currently the plan in Fedora CoreOS is to deliver content via a plain 36 | OSTree Repo and augment our strategy with either rojig or OCI if it 37 | proves useful or necessary. 38 | 39 | ## Release Streams 40 | 41 | - Originally discussed in [#22](https://github.com/coreos/fedora-coreos-tracker/issues/22). 42 | 43 | ### Production Refs 44 | 45 | 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. 46 | 47 | - `testing`: Periodic snapshot of the current Fedora release plus Bodhi `updates`. 48 | - `stable`: Promotion of a `testing` release, including any needed fixes. 49 | - `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. 50 | 51 | All of these refs will be unversioned, in the sense that their names will not include the current Fedora major version. The stream cadences are not contractual, but will initially have two weeks between releases. The stream maintenance policies are also not contractual and may evolve from those described above, but changes will preserve the use cases and intended stability of each stream. 52 | 53 | Users will be encouraged to run most of their production systems on `stable`, and a few percent of their systems on each of `next` and `testing` to catch regressions before they reach `stable`. 54 | 55 | ### Development Refs 56 | 57 | Development for the next `testing` and `next` releases will occur in development refs. These refs will be public, but will be stored in a different ostree repo from production refs. 58 | 59 | - `testing-devel`: Nightly build of the package set that will be snapshotted for the next `testing` release. 60 | - `next-devel`: Nightly build of the package set that will be snapshotted for the next `next` release. 61 | 62 | ### Mechanical Refs 63 | 64 | There will also be some additional unversioned refs for the convenience of Fedora CoreOS developers. These will be public and stored in the same ostree repo as development refs. Unlike production and development refs, mechanical refs are not curated; they're simply a snapshot of the corresponding Bodhi repos, with no package pinning and no backports of fixes. None of these refs are contractual; they might go away if we don't find them useful. 65 | 66 | - `rawhide`: Nightly snapshot of rawhide. 67 | - `branched`: Nightly snapshot of the upcoming Fedora release after it is branched. 68 | 69 | ### Out-of-Cycle Releases 70 | 71 | Due to the promotion structure described above, `stable` can contain packages that are as much as four weeks out of date. Sometimes, however, there will be an important bugfix or security fix that cannot wait a month to reach `stable` (or two weeks to reach `next` or `testing`). In that case, the fix will be incorporated into out-of-cycle releases on affected streams. These releases will not affect the regular promotion schedules; for example, a fix might sit in `testing` for only a few days before it is promoted to `stable`. 72 | 73 | If a fix is important enough for an out-of-cycle `stable` release, other affected release streams should be updated as well. 74 | 75 | In some cases it may make sense to apply a fix to `testing` but not issue an out-of-cycle release, allowing the fix to be picked up automatically when `testing` promotes to `stable`. 76 | 77 | ### Major Fedora Version Rebases 78 | 79 | The release process integrates with Fedora's release milestones in the following ways: 80 | 81 | - Fedora Beta Release 82 | - The `next` stream is switched over to the new release. 83 | - Fedora Final Freeze 84 | - The `next` stream switches to weekly releases to closely track the GA content set. 85 | - Fedora General Availability 86 | - Fedora CoreOS re-orients its release schedule in the following way: 87 | - Week -1 (Fedora "Go" Decision): `next` release: 88 | - `next` release with final Fedora GA content 89 | - Week 0 (GA release): triple release: 90 | - `stable` release promoted from previous `testing` (on N-1) 91 | - `testing` release promoted from previous `next` 92 | - `next` release contains latest Fedora N content, including Bodhi updates 93 | - Week 2: triple release: 94 | - `stable` release promoted from previous `testing`, now fully rebased to Fedora N 95 | - `testing` and `next` are now in sync 96 | 97 | We have [a checklist](https://github.com/coreos/fedora-coreos-tracker/blob/main/.github/ISSUE_TEMPLATE/rebase.md) to track the exact steps followed during a rebase. 98 | 99 | ### Deprecation 100 | 101 | Because production refs are unversioned, users will seamlessly upgrade between Fedora major releases, so compatibility must be maintained. Removal of functionality will require explicitly announced deprecations, potentially with long deprecation windows. 102 | 103 | ## Disk Layout 104 | 105 | - Originally discussed in issue [#18](https://github.com/coreos/fedora-coreos-tracker/issues/18). 106 | See also [dustymabe's comment](https://github.com/coreos/fedora-coreos-tracker/issues/18#issuecomment-409668929) 107 | summarizing the discussion in the FCOS meeting. 108 | - Filesystem details were discussed in [#33](https://github.com/coreos/fedora-coreos-tracker/issues/33). 109 | We will use XFS by default. 110 | 111 | ### Summary: 112 | 113 | - FCOS will use a "dd-able" image and ship with a standard partition layout. 114 | - The bare metal image and cloud images have the same layout. 115 | - The `/var` and root (`/`) filesystems will be XFS by default. 116 | - Anaconda will not be used for installation. 117 | - FCOS should not use the [GPT generator](https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html). 118 | - LVM should be supported, but not used by default. 119 | - Ignition will be used to customize disk layouts. 120 | 121 | FCOS should have a fixed partition layout that Ignition can modify on first boot. The installer will be similar to the 122 | Container Linux installer; the core of it will be dd'ing an image to the disk. 123 | 124 | The partition layout will support "dual EFI/BIOS" on x86_64, and will have a single root partition as XFS by default. We will support changing the root filesystem storage (but not `/boot`) via Ignition. 125 | 126 | ### Open Questions: 127 | 128 | - What do we do about 4k sector disks? We could make a "hybrid" disk image, but it technically breaks the GPT spec and 129 | may not work with poorly implemented UEFIs. 130 | - What is the exact partition layout? 131 | - Do we make /etc a ro bind mount? 132 | 133 | ## Approach towards shipping Python 134 | 135 | - Originally discussed in [#32](https://github.com/coreos/fedora-coreos-tracker/issues/32). 136 | 137 | ### Summary: 138 | 139 | *TL;DR* 140 | 141 | Fedora CoreOS group would really like to not ship python, but if we choose 142 | that we want to keep a tool or a few tools in Fedora CoreOS that use python 143 | then we should use an approach that makes python only available to the 144 | operating system and not to end users. 145 | 146 | **Note** that this does not say we will ship python. 147 | 148 | 149 | *Details* 150 | 151 | Container Linux has not shipped python in the past. Fedora is python 152 | heavy and thus python has been shipped in the past in Fedora Atomic 153 | Host. There are several reasons we've identified as reasons to not 154 | ship python in Fedora CoreOS: 155 | 156 | 1. prevent users from running scripts directly on the host 157 | 2. prevent shipping/maintaining python 158 | 3. prevent issues where user's python script needs library X that isn't installed 159 | 4. prevent security issues in python requiring a respin 160 | 5. less space used on disk + less data transmitted for updates 161 | 6. better perception we're a minimal OS 162 | 163 | Out of those we decided `#1` and `#3` were our primary concerns with 164 | shipping python. For `#4` we determined there was not a significant 165 | number of security issues to make shipping python prohibitive. We can 166 | achieve the goals for `#1` and `#3` by shipping a *system python* that 167 | is only accessible to operating system tools and not to end users. 168 | 169 | ## Identification in `/etc/os-release` 170 | 171 | Originally discussed in [#21](https://github.com/coreos/fedora-coreos-tracker/issues/21). 172 | 173 | ### Summary: 174 | 175 | We will identify a Fedora CoreOS server using the `ID=fedora` and `VARIANT_ID=coreos` 176 | fields in the `/etc/os-release` file. 177 | 178 | ## Firewall management 179 | 180 | Originally discussed in [#26](https://github.com/coreos/fedora-coreos-tracker/issues/26). 181 | 182 | ### Summary: 183 | 184 | - FCOS will ship without any ad-hoc filtering rules. By default, nodes will boot without firewall. 185 | - Components for both iptables and nft filtering will be provided (namely `iptables`, `nftables`, and `iptables-nft` packages, plus related kernel modules). 186 | - It will be possible to set up static rules (i.e. meant to be valid and unchanged for the whole node lifetime) via Ignition. 187 | - Dynamic rules (i.e. mutable at runtime) are out of scope for FCOS own toolings. 188 | Container runtimes and orchestrators take ownership of those via their own (containerized) rules managers. 189 | 190 | ## Cloud Agents 191 | 192 | Originally discussed in [#12](https://github.com/coreos/fedora-coreos-tracker/issues/12). 193 | 194 | ### Summary: 195 | 196 | - FCOS will not ship cloud agents whenever possible. 197 | - Some clouds require the OS perform tasks like signaling boot completion. For those we will re-implement that functionality in 198 | Ignition or coreos-metadata. 199 | - For the short term, if we need to include an agent we will bake it into the image. We will not have any specific 200 | mechanism for including agents. 201 | 202 | ### AWS: 203 | 204 | Originally discussed in [#66](https://github.com/coreos/fedora-coreos-tracker/issues/66). 205 | 206 | - AWS does not require a cloud agent but does require NVME EBS udev rules 207 | - The udev rules and script will be packaged in an RPM and included in FCOS with work being tracked in [#104](https://github.com/coreos/fedora-coreos-tracker/issues/104) 208 | 209 | ### Azure: 210 | 211 | Originally discussed in [#65](https://github.com/coreos/fedora-coreos-tracker/issues/65). 212 | 213 | - We've identified one major gap with not shipping the [Microsoft Azure Linux Agent](https://github.com/Azure/WALinuxAgent): the machine will not check-in and will eventually be culled by Azure for being stuck in the creation process. 214 | - This gap will be covered by work done in [coreos-metadata](https://github.com/coreos/coreos-metadata/issues/120). 215 | - One additional gap which will __not__ be covered is a lack of ephemeral disk support. We plan to ship udev rules but will not have a service which formats the disk unless we receive feature requests in the future. This was discussed in [#97](https://github.com/coreos/fedora-coreos-tracker/issues/97). 216 | - As a cosmetic issue, we should also ship a rule to [ignore SR-IOV interfaces](https://github.com/coreos/fedora-coreos-tracker/issues/115). 217 | 218 | ### DigitalOcean: 219 | 220 | Originally discussed in [#71](https://github.com/coreos/fedora-coreos-tracker/issues/71). 221 | 222 | - DigitalOcean has an [agent](https://github.com/digitalocean/do-agent) that provides instance metrics back to DO. We will not ship it. 223 | - DigitalOcean does not generally offer DHCP. Network configuration is obtained from an HTTP metadata service on a link-local address. On other platforms this is handled by cloud-init. 224 | - Networking should be configured by coreos-metadata running in the initramfs, but coreos-metadata [may need to learn to configure NetworkManager or nm-state](https://github.com/coreos/fedora-coreos-tracker/issues/111) depending on the outcome of [#24](https://github.com/coreos/fedora-coreos-tracker/issues/24). 225 | 226 | ### OpenStack: 227 | 228 | Originally discussed in [#68](https://github.com/coreos/fedora-coreos-tracker/issues/68). 229 | 230 | - OpenStack environments do not require a cloud agent 231 | - We will provide any base level of functionality with ignition and coreos-metadata 232 | 233 | ### Packet: 234 | 235 | Originally discussed in [#69](https://github.com/coreos/fedora-coreos-tracker/issues/69). 236 | 237 | - On the first boot, Packet requires the machine to phone home to report a successful boot. This will be [handled by coreos-metadata](https://github.com/coreos/coreos-metadata/issues/120). 238 | - Packet provides the IPv4 public address via DHCP, allowing a machine to acquire network via standard mechanisms. However, to obtain a private IPv4 address or a public IPv6 address (on the same interface), networking must be configured using metadata from an HTTP metadata service. This can be handled by coreos-metadata in the initramfs, but it [may need to learn to configure NetworkManager or nm-state](https://github.com/coreos/fedora-coreos-tracker/issues/111) depending on the outcome of [#24](https://github.com/coreos/fedora-coreos-tracker/issues/24). 239 | - Packet needs the serial console on x86 to be directed to `ttyS1`, not `ttyS0`, requiring [cloud-specific bootloader configuration](https://github.com/coreos/fedora-coreos-tracker/issues/110). A different serial console configuration is required on ARM64. 240 | - On many Linux OSes, Packet sets a randomized root password which is then available from the Packet console for 24 hours. This allows the serial (SOS) console to be used for interactive debugging. Container Linux, instead, enables autologin on the console by default. To avoid surprising users, Fedora CoreOS will do neither. For interactive console access, users can use Ignition to enable autologin or to set a password on the `core` account, and we'll document how to do that. 241 | 242 | ### Open questions: 243 | 244 | - What do we do about VMware, which has a very involved and intrusive "agent"? 245 | 246 | ## Supported Ignition Versions 247 | 248 | Originally discussed in [#31](https://github.com/coreos/fedora-coreos-tracker/issues/31). 249 | 250 | ### Summary: 251 | 252 | - FCOS will only support Ignition spec 3.0.0 and up. 253 | - Ignition spec 3.0.0 will break compatibilty with spec 2.x.y, although most configs will only require minor changes. 254 | - Tooling should exist to aid converting 2.x.y configs to 3.0.0 configs, although perfect automated translation will not be possible. 255 | 256 | ## Configuration Language and Transpiler 257 | 258 | - Originally discussed in issue [#129](https://github.com/coreos/fedora-coreos-tracker/issues/129). 259 | - Versioning discussed in issue [#89](https://github.com/coreos/fedora-coreos-tracker/issues/89) 260 | 261 | ### Summary: 262 | 263 | Fedora CoreOS will have a configuration language similar to the [Container Linux Configuration Language](https://coreos.com/os/docs/latest/configuration.html) named the Fedora CoreOS Configuration Language (FCCL). There will be a tool, the Fedora CoreOS Configuration Transpiler (FCCT) to convert Fedora CoreOS Configs (FCCs) to Ignition configs. 264 | 265 | The FCCL will be versioned using semver, similar to how the Ignition spec is versioned. FCCT will accept all versions of the FCCL. Each FCCL version will target exactly one Ignition spec version. 266 | This means: 267 | - Old FCCs will continue to work with new versions of FCCT without modification. 268 | - Each FCCL version will always emit the same version of Ignition config, regardless of what version of FCCT was used to transpile it. 269 | - Since FCOS will accept old (down to 3.0.0) versions of Ignition configs, old FCCs will continue to work with new FCOS releases without modification. 270 | - To use new features in new FCCT releases, users must update their configs to use the new FCCL spec. 271 | 272 | ## Security policies 273 | 274 | ### No autologin by default 275 | 276 | Originally discussed in [#114](https://github.com/coreos/fedora-coreos-tracker/issues/114). 277 | 278 | We will not enable autologin on serial or VGA consoles by default, even on platforms (e.g. Azure, DigitalOcean, GCP, Packet) which provide authenticated console access. Doing so would provide an access vector that could surprise users unfamiliar with their platform's console access mechanism and access control policy. For users who wish to use the console for debugging, we will provide documentation for using Ignition to enable autologin or to set a user password. 279 | 280 | ### Automatically disable SMT when needed to address vulnerabilities 281 | 282 | Originally discussed in [#181](https://github.com/coreos/fedora-coreos-tracker/issues/181). 283 | 284 | There have been multiple rounds of CPU vulnerabilities (L1TF and MDS) which cannot be completely mitigated without disabling Simultaneous Multi-Threading on affected processors. Disabling SMT has a cost: it reduces system performance and changes the apparent number of processors on the system. However, enabling SMT on affected systems would be an insecure default. 285 | 286 | By default, Fedora CoreOS will configure the kernel to disable SMT on vulnerable machines. This conditional approach avoids incurring the performance cost on systems that aren't vulnerable. However, it fails to protect systems affected by undisclosed SMT vulnerabilities, and it allows future OS updates to disable SMT without notice if new vulnerabilities become known. 287 | 288 | We will document this policy and its consequences, and provide instructions for unconditionally enabling or disabling SMT for users who prefer a different policy. 289 | 290 | ## Bucket Layout 291 | 292 | Originally discussed in [#189](https://github.com/coreos/fedora-coreos-tracker/issues/189). 293 | 294 | The `fcos-builds` bucket, fronted by http://builds.coreos.fedoraproject.org/ will be structured as follows: 295 | 296 | ``` 297 | / 298 | prod/ 299 | streams/ 300 | stable/ 301 | releases.json 302 | builds/ 303 | builds.json 304 | 30.1234-5/ 305 | release.json 306 | x86_64/ 307 | meta.json 308 | commitmeta.json 309 | fedora-coreos-30.8-qemu.x86_64.qcow2.gz 310 | ostree-commit-object 311 | ostree-commit.tar 312 | ... 313 | ppc64le/ 314 | ... 315 | ... 316 | testing/ 317 | next/ 318 | ... 319 | streams/ 320 | stable.json 321 | testing.json 322 | ... 323 | ``` 324 | 325 | The artifacts under e.g. `30.1234-5/x86_64/` come directly from [coreos-assembler](https://github.com/coreos/coreos-assembler). The `/streams/*.json`, `release.json`, and `releases.json` are higher-level generated metadata objects. See [#98](https://github.com/coreos/fedora-coreos-tracker/issues/98) and [#207](https://github.com/coreos/fedora-coreos-tracker/pull/207) for more information about those. 326 | 327 | The stream metadata format (under `/streams`) is intended to be stable, and stream metadata objects will contain links to artifacts in the release bucket. *Everything else about the bucket layout, including its directory structure and the formats of other metadata objects, is subject to change without notice. Third-party tooling should not rely on this structure, and should instead read metadata and artifact URLs directly from stream metadata at the officially documented URL*. 328 | 329 | ## Version numbers 330 | 331 | Originally discussed in [#81](https://github.com/coreos/fedora-coreos-tracker/issues/81) and [#211](https://github.com/coreos/fedora-coreos-tracker/issues/211). 332 | 333 | Fedora CoreOS versions will have the form `X.Y.Z.A`: 334 | 335 | - X is the Fedora major version, e.g. `31`. 336 | - Y is the datestamp that the package set was snapshotted from Fedora, e.g. `20191014`. For mechanical streams, this is the build date. For development and production streams, it's the date of the snapshot that was promoted. 337 | - For official builds, Z is a code number corresponding to the stream: 338 | 339 | Stream | Z version 340 | -- | -- 341 | next | 1 342 | testing | 2 343 | stable | 3 344 | next-devel | 10 345 | testing-devel | 20 346 | rawhide | 91 347 | branched | 92 348 | 349 | For developer builds (those not produced by the official pipeline), Z is always `dev`. 350 | 351 | These Z codes were chosen to make production versions short and simple, development versions clearly related to production versions, and mechanical versions clearly separated into a distinct group. 352 | 353 | - A is a revision number, which starts at 0 and is incremented for each new build with the same X.Y.Z parameters as an existing build. 354 | 355 | Some examples: 356 | 357 | Stream | Version | Comment 358 | -- | -- | -- 359 | next | 32.20191018.1.0 | F32-based, first release from this snapshot 360 | testing | 31.20191018.2.1 | F31-based, second release from this snapshot 361 | stable | 31.20191001.3.1 | Second stable release from the 20191001 snapshot 362 | next-devel | 31.20191018.10.10 | 11th build of the day 363 | testing-devel | 31.20191018.20.0 | 364 | rawhide | 33.20191018.91.0 | F33-based, first build of the day 365 | branched | 32.20191018.92.0 | 366 | (any developer build) | 31.20191018.dev.2 | Third build of the day 367 | 368 | 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. 369 | -------------------------------------------------------------------------------- /PRD.txt: -------------------------------------------------------------------------------- 1 | The source for this document lives at https://github.com/coreos/fedora-coreos-tracker/blob/main/PRD.txt 2 | 3 | The rendered document lives on the Fedora wiki at https://fedoraproject.org/wiki/CoreOS/PRD 4 | 5 | = Document Purpose and Overview = 6 | 7 | This is the [http://en.wikipedia.org/wiki/Product_requirements_document Product Requirements Document] for the Fedora CoreOS Working Group. It: 8 | 9 | * Describes use cases and design considerations for Fedora CoreOS. 10 | 11 | = Release/Product Overview = 12 | 13 | Fedora CoreOS is an automatically updating, minimal, monolithic, container-focused operating system, designed for clusters but also operable standalone, optimized for Kubernetes but also great without it. 14 | 15 | 16 | = Market Opportunity = 17 | 18 | The market around Linux containers and "microservices" architecture is growing rapidly, as are the technologies and processes that enable it. The demand for a container focused operating system that is automatically updated has been proven by Container Linux and Atomic Host. Fedora CoreOS is the successor to these distributions. 19 | 20 | The technologies included in Fedora CoreOS for enabling transactional system updates and containerized application hosting will have relevance to other Fedora products. Currently in the Fedora IoT and Fedora Silverblue initiatives there's an opportunity for this working group to help develop and spread these technologies to other parts of the Fedora community. 21 | 22 | == Target Market / Audience == 23 | 24 | System administrators creating containerized workloads, and organizations and users running those applications. Fedora CoreOS is particularly interested in organizations that might want to contribute back to Fedora and be involved in helping find/report/fix bugs, and develop new features. 25 | 26 | 27 | = Use Cases and Goals = 28 | 29 | === Primary Use Cases === 30 | 31 | A primary use case for Fedora CoreOS is defined as those which: 32 | 33 | * are factored into design decisions 34 | * are actively tested 35 | * receive priority in active bug fixing 36 | 37 | The primary use cases of Fedora CoreOS are: 38 | 39 | * '''Clustered server node for running Kubernetes and/OpenShift OKD''' 40 | 41 | Fedora CoreOS aims to be one of the best platforms for running Kubernetes by making it easy to set up on a known immutable OS and working closely with upstream Kubernetes to fix bugs when they occur. 42 | 43 | * '''Single server node for running containerized applications''' 44 | 45 | Fedora CoreOS aims to be one of the best platforms for running single node containerized applications by offering a container runtime and automatic updates of the base OS. 46 | 47 | == Secondary Use Cases == 48 | 49 | A secondary use case of Fedora is defined as those which: 50 | 51 | * are factored into design decisions 52 | * may be tested; note that individuals or groups within the community may make stronger guarantees depending on the use case and technology used 53 | * may have a lower priority for bug fixes, and those fixes may be completely dependent on related upstreams 54 | 55 | 56 | The secondary use cases of Fedora CoreOS are: 57 | 58 | * '''Clustered server node for running container orchestration platforms other than Kubernetes''' 59 | 60 | Fedora CoreOS will try to be a good platform for running DIY or other container orchestration platforms on top by providing a stable base OS, cluster support, and known good container runtimes. 61 | 62 | == Use Case Indifferent Goals == 63 | 64 | A use case that Fedora CoreOS is indifferent about is defined as those which: 65 | 66 | * are not factored into design decisions, but an attempt is made to not intentionally break these use cases unless the change conflicts with primary use cases 67 | * are not actively tested 68 | 69 | Fedora CoreOS is indifferent about the following use cases: 70 | 71 | * '''IoT''' 72 | 73 | The Fedora IoT Objective proposes a distinct edition for Internet of Things. Fedora IoT will use many technologies also used by CoreOS, but is a separate subproject. This separation allows both editions to put their own target audiences and use cases first when making design decisions. While Fedora CoreOS may work for IoT use cases the working group encourages users to consider the Fedora IoT edition. 74 | 75 | * '''Fedora CoreOS as a Development Platform''' 76 | 77 | Developing containerized applications, containerized runtimes, or container orchestration platforms can be done on Fedora CoreOS but it is not the goal of the working group to make significant changes to the platform to enable those use cases. 78 | 79 | === Use Case Anti-Goals === 80 | 81 | An anti-goal use case for Fedora CoreOS is defined as those which: 82 | 83 | * are not factored into design decisions. No attempt is made to not break these use cases. 84 | * the working group explicitly asks users to not explore these use cases as part of Fedora CoreOS. 85 | 86 | Based on the above definition, the anti-goal use cases for Fedora CoreOS are: 87 | 88 | * '''Host for running non-containerized applications''' 89 | 90 | Running non-containerized applications (including via package layering) is not an explicit use case of Fedora CoreOS unless named as an exception. 91 | 92 | * '''User desktop''' 93 | 94 | For desktop use cases the CoreOS group encourages users to leverage the Fedora Silverblue project. 95 | 96 | 97 | = Product Objectives = 98 | 99 | The Fedora CoreOS working group will deliver a Fedora CoreOS 100 | distribution that: 101 | 102 | * automatically updates on a regular cadence, with occasional out-of-cycle security or critical bug fix updates 103 | * delivers a small base software set (minimal, but practical), including a container runtime 104 | * has SELinux enabled by default 105 | * runs on various virtual machine, bare metal, public and private cloud platforms 106 | 107 | The first three objectives allow CoreOS to be a suitable platform for security-conscious users. 108 | 109 | 110 | = Delivery Mechanisms = 111 | 112 | Fedora CoreOS images must be easy to consume as part of a public or private cloud, as virtual machines, or on bare metal. Because we target these environments, we'll produce ISO images, downloadable VM/cloud images, and publish images to relevant public cloud services. 113 | 114 | === Where to obtain === 115 | 116 | All artifacts will be downloadable from the getfedora.org website. Similarly, for public cloud cases users can find Fedora CoreOS in the public cloud services without having to download and upload to the cloud service themselves. 117 | 118 | === Delivery Format === 119 | 120 | Artifacts will be delivered as cloud images on Amazon EC2, Azure, DigitalOcean, Google Compute Engine, and Packet; as downloadable images for OpenStack, QEMU, VirtualBox, and VMware; and as ISO images, netboot images, and installable raw images for bare metal systems. We may add other public cloud images and downloadable formats to meet demand or anticipated need. 121 | 122 | === Architectures === 123 | 124 | We are targeting 64-bit x86 initially, but plan to add other architectures starting with aarch64 and ppc64le. 125 | 126 | === Updates === 127 | 128 | Fedora CoreOS will update automatically by default. The updates will be based on the underlying OSTree technology. Updated content will be released approximately every X weeks. Updated content will be produced only for the current latest number release of Fedora and not for any previous releases of Fedora. 129 | 130 | 131 | = Measuring Success = 132 | 133 | Success looks like: 134 | 135 | * Adoption from Container Linux and Atomic Host users/communities 136 | * Third party support / targeting of Fedora CoreOS as a platform. 137 | * Increased contribution and participation in the Fedora CoreOS WG and Fedora Project in general. 138 | * Creation of new stacks by third parties based on CoreOS or underlying technology (OSTree). 139 | 140 | 141 | = Documentation = 142 | 143 | We aim to provide comprehensive documentation for both users and developers. 144 | 145 | 146 | == Fedora Project Documentation == 147 | 148 | The CoreOS Working Group will cooperate with the Documentation Project to provide documentation to users, and developers of Fedora Cloud Products. 149 | 150 | == Open Source Projects documentation == 151 | 152 | Ensuring that Fedora is well-represented, up-to-date in other open source project documentation... 153 | 154 | 155 | = About this Document = 156 | 157 | This PRD (Product Requirements Document) is an evolving document, created by the Fedora CoreOS Working Group as part of the process for designing the Fedora CoreOS project deliverable. 158 | This document will evolve over time as the purpose of the working group continues to be determined as the working group process gets under way and initial products start to get produced. 159 | 160 | == Authors == 161 | 162 | Contributors to this document include: 163 | * [[User:dustymabe|Dusty Mabe]] 164 | 165 | == Reviewers & Contributors == 166 | The following people have contributed to the development of this document, through feedback on IRC, mailing lists, and other points of contact. 167 | 168 | == Credits == 169 | 170 | The [https://fedoraproject.org/wiki/Atomic/PRD Atomic PRD] was a large inspiration for this document. 171 | 172 | == Community Information == 173 | 174 | The Fedora CoreOS Working Group is one of many teams within the Fedora Project. Communication channels are listed [https://github.com/coreos/fedora-coreos-tracker#communication-channels-for-fedora-coreos here]. Meeting/meeting log information can be found [https://github.com/coreos/fedora-coreos-tracker#meetings here]. 175 | 176 | == Approval History == 177 | 178 | Over time, it is expected that this document will undergo various rounds of review, approval, and editing; in the future, it may be rewritten for different releases of Fedora. 179 | While one can review the history of a wiki document (by clicking the "history" tab), it is useful to provide explicit indicators of any major format changes, approvals, or indications of it being in a “final” state, in a list that can allow someone to quickly see that all of the prescribed layers of approval have occured. 180 | * July 24, 2018 First Draft by dustymabe 181 | * August 17, 2018 Second Draft by dustymabe 182 | * FutureDate: Approval by SomeGroup; link to any pertinent mail announcement and/or meeting minutes 183 | 184 | == Definitions and Acronyms == 185 | 186 | * AWS: [https://aws.amazon.com/ Amazon Web Services] 187 | * Amazon EC2: Amazon Elastic Compute Cloud, a popular public IaaS, part of AWS 188 | * IaaS: Infrastructure as a Service 189 | * PaaS: Platform as a Service 190 | * SaaS: Software as a Service 191 | * PRD: Product Requirements Document 192 | * [[EPEL]]: Extra Packages for Enterprise Linux 193 | * CI: Continuous Integration 194 | * CD: Continuous Delivery or Continuous Deployment 195 | * [[SoftwareCollections | SCL]]: Software Collections 196 | * [[Category:SIGs|Special Interests Groups]]: teams in charge of some aspects of Fedora Project 197 | * BZ: [[Bugzilla]] 198 | * GUI: Graphical User Interface 199 | * CLI: Command Line Interface 200 | * API: Application Programming Interface 201 | * [[FESCo]]: Fedora Engineering Steering Committee 202 | 203 | 204 | 205 | [[Category:Product_Requirements_Document]] 206 | 207 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Welcome to the Fedora CoreOS issue tracker. This tracker will be used 2 | to discuss new features for Fedora CoreOS and also important bugs that 3 | are affecting the project. Tickets with the `meeting` label will be 4 | taken as agenda items during the meetings. This repo is to be used primarily 5 | for development purposes. If you are a user and have questions please use 6 | the [forum or the mailing list](#communication-channels-for-fedora-coreos). 7 | 8 | # Fedora CoreOS Working Group 9 | 10 | Fedora CoreOS is an automatically updating, minimal, monolithic, 11 | container-focused operating system, designed for clusters but also 12 | operable standalone, optimized for Kubernetes but also great without 13 | it. It aims to combine the best of both CoreOS Container Linux and 14 | Fedora Atomic Host, integrating technology like Ignition from Container 15 | Linux with rpm-ostree and SELinux hardening from Project Atomic. Its 16 | goal is to provide the best container host to run containerized workloads 17 | securely and at scale. 18 | 19 | The Fedora CoreOS Working Group works to bring together the various 20 | technologies and produce Fedora CoreOS. 21 | 22 | # Get Fedora CoreOS 23 | 24 | [Download Fedora CoreOS.](https://getfedora.org/coreos/download/) 25 | 26 | # Communication channels for Fedora CoreOS 27 | 28 | - Main mailing list: [coreos@lists.fedoraproject.org](https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org/) 29 | - Status mailing list: [coreos-status@lists.fedoraproject.org](https://lists.fedoraproject.org/archives/list/coreos-status@lists.fedoraproject.org/) (announcements/important messages) 30 | - Chat room: [`#coreos:fedoraproject.org` on Matrix](https://chat.fedoraproject.org/#/room/#coreos:fedoraproject.org) 31 | - Forum at [https://discussion.fedoraproject.org/tag/coreos](https://discussion.fedoraproject.org/tag/coreos) 32 | - Feature planning and important issue tracking at [github.com/coreos/fedora-coreos-tracker](https://github.com/coreos/fedora-coreos-tracker) 33 | - Website at [https://getfedora.org/coreos/](https://getfedora.org/coreos/) 34 | - Documentation at [https://docs.fedoraproject.org/en-US/fedora-coreos/](https://docs.fedoraproject.org/en-US/fedora-coreos/) 35 | - Twitter: [@fedoracoreos](https://twitter.com/fedoracoreos) 36 | 37 | # Roadmap/Plans 38 | 39 | Fedora CoreOS is available for general use and no longer in preview. We're 40 | continuing to add more platforms and functionality, fix bugs, and write 41 | documentation. Please try out Fedora CoreOS and give us feedback! 42 | 43 | # Adding Packages to Fedora CoreOS 44 | 45 | We often find people asking for a particular package to be added to the base set of 46 | packages included in Fedora CoreOS. One of the goals of Fedora CoreOS is to 47 | remain as lean as possible, without impacting overall usability for our users. 48 | Thus, new package requests are carefully scrutinized to weigh the benefits and 49 | drawbacks of adding an additional package. 50 | 51 | If you would like to propose the inclusion of a new package in the base set of packages, 52 | please file a [new package request](https://github.com/coreos/fedora-coreos-tracker/issues/new/choose). 53 | 54 | # Releases 55 | 56 | See [RELEASES.md](RELEASES.md). 57 | 58 | # Meetings 59 | 60 | The Fedora CoreOS Working Group has a weekly meeting. The meeting usually 61 | happens in 62 | [#meeting-1:fedoraproject.org](https://matrix.to/#/#meeting-1:fedoraproject.org) 63 | on Matrix and the schedule for the meeting can be found here: 64 | https://calendar.fedoraproject.org/CoreOS/ Currently, meetings are at 65 | [`16:30 UTC`](https://time.is/16:30+UTC) on Wednesdays. 66 | 67 | As the 68 | [Matrix bridge to Libera Chat is shutdown](https://matrix.org/blog/2023/11/28/shutting-down-bridge-to-libera-chat/), 69 | you can not attend the meeting from IRC and you have to join using Matrix. 70 | 71 | ## Steps to run the meeting 72 | 73 | The fedora meeting host can follow the guide which is curated by the [fcos-meeting-action](https://github.com/coreos/fcos-meeting-action) repo. 74 | Every Wednesday a new checklist will be available in the form of a issue in the fcos-meeting-action repo, which can be used to run the meeting. 75 | 76 | If the action meeting repo is not available for some reason, the host can follow the below steps to run the meeting. 77 | 78 |
79 | Legacy Meeting steps 80 | 81 | - `cd` to a local checkout of this repo and `git pull` 82 | - Ping [meeting people](https://github.com/coreos/fedora-coreos-tracker/blob/main/meeting-people.txt) in `#fedora-coreos` on libera.chat 83 | - `bash meeting-people.txt` 84 | - copy lines of output and paste into 85 | [`#coreos:fedoraproject.org`](https://chat.fedoraproject.org/#/room/#coreos:fedoraproject.org) 86 | on Matrix 87 | - Navigate to 88 | [`#meeting-1:fedoraproject.org`](https://matrix.to/#/#meeting-1:fedoraproject.org) 89 | on Matrix 90 | - Type: 91 | - `!startmeeting fedora_coreos_meeting` 92 | - `!topic roll call` 93 | 94 | Wait for 2-4 minutes for people to check in for the roll call. 95 | 96 | - `!topic Action items from last meeting` 97 | 98 | Find the last meeting log from [meetbot](https://meetbot.fedoraproject.org/) 99 | and post the action items in the meeting for people to update the status of. 100 | 101 | - After they are done move to each `meeting` ticket from 102 | [this tracker](https://github.com/coreos/fedora-coreos-tracker/labels/meeting) 103 | 104 | Do the following for each ticket 105 | 106 | - `!topic` Ticket subject 107 | - `!link ` 108 | 109 | During the meeting, you can give people action items for them to complete: 110 | 111 | - `!action ` description of what needs to be done 112 | 113 | When all topics are over, go for open floor: 114 | 115 | - `!topic Open Floor` 116 | 117 | After open floor, end the meeting. 118 | 119 | - `!endmeeting` 120 | 121 | Then, when convenient: 122 | 123 | - Remove `meeting` labels from [tickets that were discussed](https://github.com/coreos/fedora-coreos-tracker/labels/meeting) 124 | 125 | - Send an email to [coreos@lists.fedoraproject.org](mailto:coreos@lists.fedoraproject.org) with the 126 | details of the meeting from [meetbot page](https://meetbot.fedoraproject.org/). 127 | Minutes in textual format are directly available using `.txt` as URL extension. 128 | It's easiest to get the Minutes/Minutes (text)/Log URLs by copying the 129 | footer that Meetbot prints after `#endmeeting`. You can see examples in the 130 | [archives](https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org/); 131 | the usual format follows: 132 | 133 | ``` 134 | Subject: Fedora CoreOS Meeting Minutes year-mm-dd 135 | 136 | Body: 137 | 138 | Minutes: 139 | Minutes (text): 140 | Log: 141 | 142 | 143 | ``` 144 |
145 | 146 | # Voting 147 | 148 | On some topics we will need to vote. The following rules apply to the voting 149 | process. 150 | 151 | ## For Regularly Scheduled Meetings 152 | 153 | A quorum for the meeting is 5 people, or 51% of the members of the WG listed 154 | below, which ever is lower. Voting items must pass with a majority of the 155 | members voting at the meeting. 156 | 157 | ## For General Ad-Hoc Votes 158 | 159 | - All ad-hoc votes will be held via [tracker issues](https://github.com/coreos/fedora-coreos-tracker/). 160 | - Ad-hoc votes must be announced on the current primary mailing list for Fedora Atomic (atomic-devel). 161 | - Ad-hoc votes must be open for at least three working days (see below) after the announcement. 162 | 163 | At least 5 people must vote, or 51% of the WG membership, whichever is 164 | less. Votes are "+1" (in favor), "-1" (against), or +0 (abstain). Votes 165 | pass by a simple majority of those voting. 166 | 167 | ## For Urgent Ad-Hoc Votes 168 | 169 | - All ad-hoc votes will be held via tracker issues in the fedora-coreos-tracker repo. 170 | - Ad-hoc votes must be announced on the current primary mailing list for Fedora CoreOS. 171 | - Ad-Hoc votes must be open for at least three hours after the announcement. 172 | 173 | At least 5 people must vote, or 51% of the WG membership, whichever is less. Votes are "+1" (in favor), "-1" (against), or +0 (abstain). Votes pass by a 2/3 majority of those voting (round up). 174 | 175 | Working days: non-holiday weekdays. Relevant holidays are the national holidays of the USA, Western Europe, and India. 176 | 177 | # Working Group Members and Points of Contact 178 | 179 | Please see [meeting-people.txt](https://github.com/coreos/fedora-coreos-tracker/blob/main/meeting-people.txt). 180 | 181 | # Metrics 182 | 183 | To view CountME stats you can use a tool called 184 | [sqlitevis](https://sqliteviz.com/) to view the 185 | CountME database and make graphs. This can easily be done with a 186 | single URL but due to [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS) 187 | you have to run your browser in a specific mode to allow the 188 | application to download the database and the inquiries file: 189 | 190 | ``` 191 | chromium-browser --disable-web-security --user-data-dir=~/chrome-disable-web-security/ 192 | # OR 193 | google-chrome-stable --disable-web-security --user-data-dir=~/chrome-disable-web-security/ 194 | ``` 195 | 196 | Now navigate to 197 | [this](https://sqliteviz.com/app/#/load?data_url=https%3A%2F%2Fdata-analysis.fedoraproject.org%2Fcsv-reports%2Fcountme%2Ftotals-countme.db&data_format=sqlite&inquiry_url=https%3A%2F%2Fraw.githubusercontent.com%2Fcoreos%2Ffedora-coreos-tracker%2Frefs%2Fheads%2Fmain%2Fmetrics%2Ffcos-sqlitevis.json) 198 | URL in the browser and it should autoload the database and the inquiries. This 199 | URL was generated from the [sqlitevis docs](https://sqliteviz.com/docs/sharing/). 200 | -------------------------------------------------------------------------------- /RELEASES.md: -------------------------------------------------------------------------------- 1 | # Fedora CoreOS Releases 2 | 3 | FCOS releases normally happen every 2 weeks. In addition, 4 | there may be asynchronous releases for e.g. CVEs or bug 5 | fixes. 6 | 7 | For more details, see 8 | [the design doc](Design.md#release-streams). 9 | 10 | ## Streams 11 | 12 | There are 3 primary streams: `stable`, `testing`, and 13 | `next`. The `next` stream either tracks `testing` or the 14 | next major version of Fedora. Content in `testing` is 15 | promoted to `stable` after 2 weeks. 16 | 17 | For more details, see 18 | [the design doc](Design.md#release-streams). 19 | 20 | ## Versioning 21 | 22 | FCOS versions are of the form `X.Y.Z.A`, where `X` is the 23 | Fedora major version, `Y` is the date of the Fedora RPM 24 | snapshot, `Z` is a stream identifier, and `A` is a revision 25 | number. 26 | 27 | Since `stable` releases are promoted from `testing`, their 28 | `Y` dates will usually be 2 weeks behind `testing`. 29 | 30 | For more details, see 31 | [the design doc](Design.md#version-numbers). 32 | 33 | ## Schedule 34 | 35 | The release schedule and release owners are tracked in a 36 | [HackMD document](https://hackmd.io/WCA8XqAoRvafnja01JG_YA). 37 | -------------------------------------------------------------------------------- /docs/20210204_fcos_official_edition.md: -------------------------------------------------------------------------------- 1 | # Fedora CoreOS Meetup - Fedora CoreOS as an Official Edition 2 | 3 | recording : https://www.youtube.com/watch?v=t5VAw8NRXNc 4 | 5 | Fedora Change : https://fedoraproject.org/wiki/Changes/FedoraCoreOS 6 | 7 | Key concepts : 8 | * There is no Fedora CoreOS 33 or 34, I don't think we want to align with the 6 months release cadence of other Fedora Editions. 9 | * How can we integrate within Fedora's process, keeping our fortnigthly release cycle. 10 | 11 | 12 | General Feedback was how do we integrate with the Fedora process 13 | 14 | Fedora's [Edition promotion policy](https://docs.fedoraproject.org/en-US/council/policy/edition-promotion-policy/) 15 | * Development and how we integrate with Fedora's change proposal process ? (Review, Propose Changes) 16 | * Go/No Go process ? Release Blockers 17 | * Release Criteria ? 18 | * When do we switch streams to the latest Fedora base (F33 -> F34, etc...)? 19 | * How do we coordinate with other teams 20 | * Docs 21 | * Marketing 22 | * Translation 23 | * Magazine 24 | * Web 25 | * How much effort do we want to put into making FCOS an edition ? What are the benefits ? 26 | * Have you asked anyone who has gone through this process if it was useful to them? 27 | 28 | ## Notes 29 | 30 | - [miabbott/cverna] Short introduction 31 | - [mattdm] how does "we don't have releases" work with the release blocker process? 32 | - [bgilbert] we ship the stable stream later than major Fedora releases for this reason; may not be desirable in all cases. if there is a blocker that only affects FCOS, we may not want to hold the other releases. 33 | - [mattdm] publicity is a factor of concern here 34 | - [bcotton] user perspective on release day is problematic; "why am i getting older Fedora bits?" 35 | - [walters] we think we can address all these concerns over time. i.e. ubuntu has similar issues with software upater/apt - https://www.reddit.com/r/Ubuntu/comments/aofv57/software_updater_lags_behind_apt/ 36 | - [sumantro] Blocker Bugs for Fedora tracked in BZ; FCOS tracks issues in GH 37 | - [bgilbert] FCOS is an appliance, uses automatic updates. Breaking updates incentivizes users to turn off auto-updates. Streams exist towards this goal. 38 | - [mattdm] automatic updates are a selling point; we should use it to our advantage 39 | - [travier/bcotton/mattdm] 40 | - [jligon] e.g. If I want to remove Docker from FCOS, do I submit a change to FCOS only, Fedora proper, somewhere on GH? 41 | - [mattdm] feels like a self-contained change; would be discussed by stakeholders and publicized appropriately (picked up by LWN, Phoronix, etc) 42 | - [mattdm] FCOS changes being part of existing Fedora change process is desirable 43 | - [walters] bootupd should have been a change request; but sometimes we need to ship something downstream faster than Fedora allows 44 | - [bgilbert] prefer not stacking big changes around major release; easier for change management 45 | - [bcotton] window between self-contained change proposal and GA is only 3months 46 | - [cglombek] there are still usecases where Fedora Server is better suited (firewall, RPM modules, etc) 47 | - [mattdm] FCOS will likely sit alongside Fedora Server for a while 48 | - [walters] I don't think it's a good idea overall to chain FCOS Edition status into Server's edition status 49 | - [mattdm] should develop an async process for ??? 50 | - [cverna] promoting between streams is gated on testing; what does the formalized process look like 51 | - [cglombek] https://github.com/coreos/enhancements that are going to affect the rest of Fedora, we should "upstream" those enhancements to proper Fedora Change Requests. conversely, Fedora Chagne Requests that affect FCOS should get better review by FCOS 52 | - [walters] we could use an arbitrary component in BZ to capture problems for FCOS 53 | - [dmabe] there is an FCOS component, but it directs folks to use GH issue tracker 54 | - [sumantro] get some basic criteria around stream promotion; can't catch everything in CI; https://fedoraproject.org/wiki/Fedora_Release_Criteria 55 | - [walters] A good example of not-CI currently for us is multi-arch 56 | - [bgilbert] our decision process so far has been case-by-case and consensus-driven 57 | - [jlebon] we should be doing more talking/communication on Fedora devel around change requests that affect FCOS 58 | - [jligon] is there a tradeoff where becoming an official top-level edition where some decision making is surrendered? 59 | - [bcotton] there is some latitude for editions for change proposals; there is marketing/UX benefits to be closer to the rest of Fedora. tl;dr - case by case basis 60 | - [travier] our release criteria exists in CI; we do evaluate each update that we ship is safe to use. when issues are found, we have more options to prevent those issues from being released (i.e downgrades, pinned packages, etc) 61 | - [bgilbert] we snapshot bodhi stable that gets promoted into the testing stream; pkgs are not pinned for an extended amount of time. we do more post-processing than most of Fedora. 62 | - [mattdm] it would be beneficial to check in with mindshare team regularly 63 | - **[sumantro] would like to volunteer to be mindshare rep for FCOS** 64 | 65 | -------------------------------------------------------------------------------- /docs/20210204_growing_fcos_community.md: -------------------------------------------------------------------------------- 1 | # 20210204_Growing-FCOS-Community 2 | 3 | recording: https://www.youtube.com/watch?v=HSuBWeosAvQ 4 | 5 | - Execution 6 | - Stability: we might lose users if we have instability and "manual intervention" 7 | - Availability in more cloud providers 8 | 9 | - Freely available information/resources 10 | - Publishing release notes 11 | - https://github.com/coreos/fedora-coreos-tracker/issues/194 12 | - More comprehensive documentation 13 | 14 | - Outreach 15 | - Community event coordination 16 | - especially at conferences we don’t normally have representation 17 | - but also making sure we are present at our regular conferences 18 | - Working with more upstream projects that integrate Fedora CoreOS 19 | - Typhoon has picked us up on their own 20 | - Have others tried and had trouble? 21 | - GSoC/Outreachy FCOS projects 22 | 23 | - Staying in the conversation 24 | - More articles/posts about Fedora CoreOS 25 | - Fedora Magazine, opensource.com, personal blogs, etc 26 | - Podcasts, etc.. 27 | - Boosting our Twitter presence 28 | 29 | - Indirect Progress 30 | - Promoting containerized workflows 31 | - Helping to containerize the world 32 | - If it's not easy to run XYZ workflow in containers people can't use FCOS 33 | 34 | ## Running Notes 35 | 36 | Recurring Fedora Events: 37 | - Nest with Fedora/Flock to Fedora 38 | - Release Parties (2 per year) 39 | - Fedora Women's Day 40 | - Video Council Meetings 41 | - Social Hours 42 | 43 | Fedora Content outlets: 44 | - Community Blog: https://communityblog.fedoraproject.org/writing-community-blog-article/ 45 | - Fedora Magazine: https://docs.fedoraproject.org/en-US/fedora-magazine/contributing/ 46 | - Fedora Planet: http://fedoraplanet.org/ 47 | - Podcast: https://x3mboy.fedorapeople.org/podcast/ 48 | - Fedora Classroom: https://fedoraproject.org/wiki/Classroom 49 | - Fedora Youtube: https://www.youtube.com/channel/UCnIfca4LPFVn8-FjpPVc1ow 50 | 51 | 52 | Fedora Resources: 53 | - Request swag: https://docs.fedoraproject.org/en-US/mindshare-committee/procedures/swag/ 54 | - HopIn is accessible to Fedora. A formal process is currently being documented by Mindshare. You can request this resource here: https://pagure.io/mindshare/issues 55 | - Community surveys are accessible to Fedora. There is a drop down template in the Mindshare repo for this request. https://pagure.io/mindshare/issues 56 | - IRL Events (someday): https://docs.fedoraproject.org/en-US/mindshare-committee/small-events/ 57 | - Design requests: https://pagure.io/design/issues 58 | - Fedora Badges: https://badges.fedoraproject.org/ 59 | - https://pagure.io/fedora-badges/issues 60 | - How Do You Fedora? interviews: https://fedoramagazine.org/series/how-do-you-fedora/ 61 | 62 | 63 | 64 | [cverna] What is our messaging to other conferences? 65 | [jbrooks] We can produce a slide deck that can be reused/customized for talks/presentation 66 | [walters] Fedora very RPM-centric; would love to push us towards more pure containers 67 | [travier] tried to run Fedora images for containerizing Matrix and hit issues; having trusted container images outside Dockerhub would be great 68 | [cglombek] not producing enough Fedora containers; maintaining containers in Fedora has high requirements (i.e. must be packagers). also facing problem of where to publish community operators in OKD space. 69 | [jbrooks/dmabe] identified a problem that we don't have the applications people want in our sphere of control (i.e don't have trusted containers for all apps). how can we improve the Fedora container story? 70 | [cverna] need to have a better idea of who we are targeting with our content 71 | [mperez] have connections with linux unplugged, can get FCOS discussed there; interested in producing more video content for communities (i.e. https://ceph.io/community/meetings/). working on templates for hosting this style of content. 72 | [mnordin] FCOS has access to all the Fedora community tools above; willing to help move tickets along in various community resources 73 | [sumantro] Fedora Classrooms would be a good outreach point 74 | [sumantro] Adding FCOS to https://whatcanidoforfedora.org/ will be great. 75 | [vipul] A bit different thing: opening a few GSoC/Outreachy projects can also bring a lot of eyes on the project. They are often not the best but it can help and also identify close all gaps in "How can I get started with FCOS" documentation 76 | [dmabe/mperez] measuring stats for MLs, forums, GH tracker may be informative 77 | [mnordin] would recommend starting with a user survey to gather a baseline from where to start from 78 | [mperez] example survey - https://tracker.ceph.com/attachments/download/5323/Ceph%20User%20Survey%202020%20(3).pdf 79 | -------------------------------------------------------------------------------- /docs/ci-and-builds.md: -------------------------------------------------------------------------------- 1 | # CoreOS CI+build systems overview 2 | 3 | Fedora CoreOS is tied/related to 3 major things: 4 | 5 | - Upstream git repositores like github.com/coreos/ignition, github.com/coreos/rpm-ostree, github.com/coreos/fedora-coreos-config, etc. 6 | - Actual releases of Fedora CoreOS via [the pipeline](https://github.com/coreos/fedora-coreos-pipeline) 7 | - Downstream [RHEL CoreOS](https://github.com/openshift/os) 8 | 9 | ## Infrastructure 10 | 11 | - Github (specifically [the coreos namespace](https://github.com/coreos/)) 12 | - [quay.io](https://quay.io), specifically the [coreos-assembler](https://quay.io/coreos/coreos-assembler) namespace 13 | - [CoreOS CI Jenkins](https://github.com/coreos/coreos-ci) 14 | - [Fedora infrastructure](https://fedoraproject.org/wiki/Infrastructure) 15 | - [OpenShift Prow](https://docs.ci.openshift.org/) 16 | 17 | --- 18 | 19 | ## Upstream CI 20 | 21 | Most active repositories in the `coreos/` project are hooked up to at least one of 3 CI systems, being CoreOS CI Jenkins, Github Actions, or OpenShift Prow. These 3 are the ones we are focusing on. 22 | 23 | ### CoreOS CI Jenkins 24 | 25 | It is what we use on various repositories, and is how FCOS is released today via [the pipeline](https://github.com/coreos/fedora-coreos-pipeline). 26 | We have a lot of institutional knowledge around this and it gives us a place where we can easily control the end-to-end interactions. Jenkins is a well understood tool. 27 | 28 | This is deployed in [CentOS CI](https://wiki.centos.org/QaWiki/CI) which is a bare metal OpenShift cluster where nested virt is enabled. 29 | 30 | Also of key relevance is the [coreos-ci-lib](https://github.com/coreos/coreos-ci-lib) repository. 31 | 32 | ### OpenShift Prow 33 | 34 | Prow is heavily oriented towards testing OpenShift *container* components. However, as of recently we enabled nested virt on the `build02` GCP cluster, which means we can create "container native" flows that still test the OS with [coreos-assembler](https://github.com/coreos/coreos-assembler/). 35 | 36 | A specific reason to include Prow is that it contains tight integration with OpenShift which we need for RHCOS, and it is also maintained and staffed by a team that e.g. also contains a budget and secrets for running infrastructure in public clouds. 37 | 38 | Examples can be found in the [openshift/release coreos/ folder](https://github.com/openshift/release/tree/main/ci-operator/config/coreos). 39 | 40 | ### GitHub Actions 41 | 42 | Free for small scale, nice to use. This is a good option for per-repository specific things that don't need centralization. 43 | 44 | A good use case is e.g. validating rustfmt. 45 | 46 | Examples: 47 | 48 | - https://github.com/coreos/rpm-ostree/blob/main/.github/workflows/rust-lints.yml 49 | 50 | --- 51 | 52 | ## quay.io/coreos-assembler namespace 53 | 54 | A key aspect of Fedora CoreOS as well as RHEL CoreOS is [coreos-assembler](https://github.com/coreos/coreos-assembler). As of today, we build it in quay.io and deliver it that way in the `quay.io/coreos-assembler` namespace. The list of administrators for this namespace is managed independently of anything else. If you think you need administrator access, file a ticket or ask on [`#coreos:fedoraproject.org` on Matrix](https://chat.fedoraproject.org/#/room/#coreos:fedoraproject.org). 55 | 56 | ### The buildroot container: quay.io/coreos-assembler/fcos-buildroot:testing-devel 57 | 58 | Since [this pull request](https://github.com/coreos/fedora-coreos-config/pull/740), there is also a FCOS-oriented "buildroot" container that can be used in all CI systems. 59 | 60 | ## Fedora Infrastructure 61 | 62 | Maintained by a distinct team. FCOS and our container images include most content derived from Koji/Bodhi etc. 63 | 64 | It would potentially make sense to have some of our containers built in Fedora too, such as coreos-assembler. That would give us e.g. multi-arch. But that is not being pursued currently. 65 | 66 | -------------------------------------------------------------------------------- /docs/fedora-coreos-kernel-bisect.md: -------------------------------------------------------------------------------- 1 | 2 | # Kernel regressions need bisecting 3 | 4 | Sometimes we encounter kernel regressions and it is valuable to 5 | identify the exact commit where a regression was introduced. An example 6 | of this would be 7 | [this issue for nodes booting in AWS](https://github.com/coreos/fedora-coreos-tracker/issues/1066#issuecomment-1019560658). 8 | 9 | There are various strategies for how to determine the exact kernel 10 | commit where a regression was introduced. Which strategy is most 11 | efficient depends on the problem. Here they are: 12 | 13 | 1. directly building and installing the kernel from kernel source git repo 14 | 2. directly building and creating an RPM from the kernel source git repo 15 | 16 | For `1.`, it only works if you can reproduce the problem on the 17 | traditional `yum`/`dnf` based Fedora (like Fedora Cloud). If, however, 18 | the problem only presents itself on Fedora CoreOS or is much easier to 19 | reproduce on Fedora CoreOS (i.e. a `kola` test) then you'll want to 20 | build the `rpm` (`2.`) and consume it that way. 21 | 22 | ## Kernel Source git Repos 23 | 24 | There are a few kernel source git repositories to know about: 25 | 26 | - `git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git` 27 | - Where the latest upstream development happens 28 | - `git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/` 29 | - Where stable/LTS tags are handled (backports to stable branches happen here) 30 | - `https://gitlab.com/cki-project/kernel-ark.git` 31 | - The `kernel-ark` repo where Red Hat patches/branches are maintained 32 | 33 | The `kernel-ark` repo contains various branches used for feeding into 34 | the [Fedora dist-git repo](https://src.fedoraproject.org/rpms/kernel). 35 | Here's a summary of what those branches are used for: 36 | 37 | 38 | - `os-build` 39 | - The latest bits that track the under development yet to be release kernel. 40 | - `fedora-6.3` 41 | - Follows a particular released kernel stream. This is where things are 42 | merged before they are fed into dist-git. If you want a commit reverted 43 | this is where it will land first. 44 | - `ark-infa` 45 | - This branch contains all the Red Hat bits and nothing else. It can be merged 46 | on top of any other branch and then a SRPM can be created (`make dist-srpm`) 47 | for building using `rpmbuild --rebuild /path/to/srpm`. 48 | 49 | ## Creating a Kernel Build Environment 50 | 51 | If running the kernel builds on a Fedora Cloud base machine where you 52 | can install the kernel directly then you can set up the kernel build 53 | environment directly in the VM. If not you'll probably want to use a 54 | container for your kernel builds. Here's how to start up a container: 55 | 56 | ``` 57 | podman run -it --name=kbuild -v /path/to/kernel/git/:/path/to/kernel/git/ registry.fedoraproject.org/fedora:38 58 | ``` 59 | 60 | NOTE: try to use the same Fedora Cloud or Fedora container version as 61 | the version of Fedora you are targetting. 62 | 63 | Once inside the VM or container we need to install some software to build the kernel: 64 | 65 | ``` 66 | sudo dnf update -y && \ 67 | sudo dnf install -y make rpm-build rsync 'dnf-command(builddep)' && \ 68 | sudo dnf builddep -y kernel 69 | # reboot here if in a VM 70 | ``` 71 | 72 | We can now make changes to the git repo (revert commits, etc) and run a few 73 | commands to build the kernel. Before building we need to copy down the config 74 | from the kernel dist-git repo and disable making a DEBUG kernel if it was enabled, 75 | which makes very large files: 76 | 77 | ``` 78 | cd /path/to/kernel/git/ 79 | RELEASE=f38 # or RELEASE=rawhide 80 | curl "https://src.fedoraproject.org/rpms/kernel/raw/${RELEASE}/f/kernel-x86_64-fedora.config" > .config.fedora 81 | cp .config.fedora .config 82 | sed -i 's/CONFIG_DEBUG_KERNEL=y/CONFIG_DEBUG_KERNEL=n/' .config 83 | ``` 84 | 85 | ## 1. Directly Building and Installing the Kernel from Kernel Source git repo 86 | 87 | To build and install the kernel directly on the system (i.e. on Fedora Cloud Base) 88 | you can run the following: 89 | 90 | ``` 91 | # Set make target. See https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec 92 | make_target=bzImage # for x86_64 or vmlinux(ppc64le) or vmlinuz.efi(aarch64) 93 | make olddefconfig 94 | make -j$(nproc) $make_target 95 | make -j$(nproc) modules 96 | sudo make modules_install 97 | sudo make install 98 | ``` 99 | 100 | On a Fedora Cloud base system the /boot partition is low on extra 101 | space. In order to iterate (i.e. when running a `git bisect`) you can 102 | restore the system back to it's old state before continuing. First, 103 | modify the Makefile and set `EXTRAVERSION = bisect` and also 104 | take a backup of the grub config: 105 | 106 | ``` 107 | sudo cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.bak 108 | ``` 109 | 110 | Then run the following script to build and install the kernel: 111 | 112 | ``` 113 | cat build.sh 114 | #!/bin/bash 115 | set -eux -o pipefail 116 | cp .config.fedora .config 117 | sed -i 's/CONFIG_DEBUG_KERNEL=y/CONFIG_DEBUG_KERNEL=n/' .config 118 | # Set make target. See https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec 119 | make_target=bzImage # for x86_64 or vmlinux(ppc64le) or vmlinuz.efi(aarch64) 120 | make olddefconfig 121 | make -j$(nproc) $make_target 122 | make -j$(nproc) modules 123 | sudo make modules_install 124 | sudo make install 125 | ``` 126 | 127 | After testing and before running the next build I would restore and 128 | free space with this clean script: 129 | 130 | ``` 131 | cat clean.sh 132 | #!/bin/bash 133 | set -eux -o pipefail 134 | sudo cp /boot/grub2/grub.cfg.bak /boot/grub2/grub.cfg 135 | sudo rm -vf /boot/initramfs*bisect* /boot/vmlinuz-*bisect* /boot/System.map-*bisect* 136 | sudo rm -rf /lib/modules/*bisect* 137 | ``` 138 | 139 | Then you can automate with: 140 | 141 | ``` 142 | bash clean.sh && bash build.sh 143 | ``` 144 | 145 | ## 2. Directly Building and Creating an RPM from the Kernel Source git repo 146 | 147 | In this scenario we're creating an RPM that can either then be package 148 | layered on an existing FCOS system or used as input to a `cosa build`. 149 | 150 | The commands here are: 151 | 152 | ``` 153 | make olddefconfig 154 | make -j$(nproc) binrpm-pkg 155 | ``` 156 | 157 | ### Package Layering the Kernel RPM 158 | 159 | After copying the built kernel to the target machine you can install it with an override. 160 | Example: 161 | 162 | ``` 163 | sudo rpm-ostree override replace ./kernel-5.17.0_rc8-1.x86_64.rpm --remove=kernel-core --remove=kernel-modules 164 | ``` 165 | 166 | ### Doing a Build with COSA 167 | 168 | Then copy the built RPM into the `overrides/rpm` folder under the COSA build directory. 169 | After that you should be able to `cosa fetch --with-cosa-overrides && cosa build` like normal. 170 | 171 | While iterating you should be able to skip the `cosa fetch` step. Just delete the old 172 | RPM out of `overrides/rpm`, put the new one in place and then `cosa build`. 173 | 174 | 175 | ## Performing a Kernel Bisect 176 | 177 | Now that we know how to build and use a kernel in various ways the bisect is 178 | the easy part. Just follow the 179 | [upstream kernel documentation](https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html) 180 | for doing a `git bisect` and repeat the build/test steps in between each step. 181 | 182 | ## Reporting issues upstream 183 | 184 | Unfortunately the kernel doesn't have any git forge structure. It's 185 | mostly email and mailing lists. If you want to report an issue 186 | upstream you can run a command to give you what people/lists to email: 187 | 188 | ``` 189 | commit=abcdef 190 | git format-patch --stdout "${commit}^..${commit}" | \ 191 | ./scripts/get_maintainer.pl --norolestats 192 | ``` 193 | 194 | example: 195 | 196 | ``` 197 | $ commit=a09b314 198 | $ git format-patch --stdout "${commit}^..${commit}" | ./scripts/get_maintainer.pl --norolestats 199 | Jens Axboe 200 | linux-block@vger.kernel.org 201 | linux-kernel@vger.kernel.org 202 | ``` 203 | 204 | ## Testing out fixes with Fedora's kernel 205 | 206 | Once you have a proposed fix/patch you can easily build a Fedora kernel RPM by 207 | adding your patch to the [`linux-kernel-test.patch` file](https://docs.fedoraproject.org/en-US/quick-docs/kernel/testing-patches/#_applying_the_patch) 208 | in the [kernel distgit repo](https://src.fedoraproject.org/rpms/kernel). 209 | 210 | After adding your patch you can then use `fedpkg` to build a new 211 | kernel for your target architecture. For example: 212 | 213 | ``` 214 | fedpkg scratch-build --srpm --arch=x86_64 215 | ``` 216 | 217 | Once the build is complete you can grab the RPMs using the `koji` CLI: 218 | 219 | ``` 220 | koji download-task 221 | ``` 222 | 223 | Placing these RPMs into the `overrides/rpm` directory and do a new COSA build 224 | will give you a CoreOS build with the patched kernel. 225 | 226 | After the tested patch looks good you can then open a PR to the `fedora-X.Y` 227 | branch in the `kernel-ark` repo. See the above 228 | [Kernel Source git Repos](#kernel-source-git-repos) 229 | section for more details. 230 | -------------------------------------------------------------------------------- /docs/fedora-coreos-systemd-bisect.md: -------------------------------------------------------------------------------- 1 | 2 | # Systemd regressions need bisecting 3 | 4 | Similar to the kernel, systemd is often a core component of our 5 | stack that has regressions that aren't easy to identify just by 6 | inspecting a changelog. 7 | 8 | ## Systemd Source git Repos 9 | 10 | There are a few kernel source git repositories to know about: 11 | 12 | - `https://github.com/systemd/systemd.git` 13 | - Where the latest upstream development happens 14 | - `https://github.com/systemd/systemd-stable.git` 15 | - Where stable/LTS tags are handled (backports to stable branches happen here) 16 | 17 | There is also the [Fedora dist-git repo](https://src.fedoraproject.org/rpms/systemd). 18 | 19 | ## Creating a Kernel Build Environment 20 | 21 | You can use a container to build systemd from upstream. 22 | 23 | ``` 24 | SHARED=/path/to/shared/directory/ 25 | RELEASE=38 26 | podman run -it --name=systemdbuild -v "${SHARED}:${SHARED}" "registry.fedoraproject.org/fedora:${RELEASE}" 27 | ``` 28 | 29 | ``` 30 | sudo dnf update -y && \ 31 | sudo dnf install -y make rpm-build rsync 'dnf-command(builddep)' && \ 32 | sudo dnf builddep -y systemd 33 | ``` 34 | 35 | We can now make changes to the git repo (revert commits, etc) and run a few 36 | commands to build systemd. If doing a 37 | [`git` bisect](https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html) 38 | run the commands needed to start the bisect. 39 | 40 | ## Doing the systemd build/test 41 | 42 | To build systemd you can run the following commands. These commands 43 | were adapted from the notes in the 44 | [Systemd README](https://github.com/systemd/systemd/blob/579fbe5b789cbee10546f6274c39be311e71e49c/README#L233-L247). 45 | 46 | 47 | ``` 48 | meson setup build/ 49 | ``` 50 | 51 | And then the following can be iterated upon for each commit to test: 52 | 53 | ``` 54 | export DESTDIR=/path/to/shared/directory/fcos/overrides/rootfs/ 55 | ninja -C build && ninja -C build install 56 | ``` 57 | 58 | NOTE: If you run into `permission denied` errors when copying the files around check for SELinux denails. 59 | 60 | Now you can run COSA to build/test. From the COSA directory: 61 | 62 | ``` 63 | cosa build && cosa kola run mytest 64 | ``` 65 | 66 | Now you can iterate until you find the problematic commit. 67 | -------------------------------------------------------------------------------- /docs/testing-project-documentation-changes.md: -------------------------------------------------------------------------------- 1 | # Testing changes for GitHub Pages hosted project documentation 2 | 3 | The first option makes it easy to link to rendered changes for code review but 4 | is slower for rapid changes or iteration where the second option is faster. 5 | 6 | ## Option 1: Deploying to your own GitHub Pages sub domain 7 | 8 | - Replace `coreos` with your GitHub username in `docs/_config.yml` on top of 9 | your other changes: 10 | ``` 11 | docs/_config.yml | 2 +- 12 | 1 file changed, 1 insertion(+), 1 deletion(-) 13 | 14 | diff --git a/docs/_config.yml b/docs/_config.yml 15 | index 3ab720a0..801cbb9d 100644 16 | --- a/docs/_config.yml 17 | +++ b/docs/_config.yml 18 | @@ -1,7 +1,7 @@ 19 | title: coreos/coreos-installer 20 | description: CoreOS Installer documentation 21 | baseurl: "/coreos-installer" 22 | -url: "https://coreos.github.io" 23 | +url: "https://your_github_username.github.io" 24 | # Comment above and use below for local development 25 | # url: "http://localhost:4000" 26 | permalink: /:title/ 27 | ``` 28 | - Push the full changes to the main branch of your GitHub repo fork 29 | - Enable GitHub Pages for the main branch, using `/` as root 30 | - Wait for approximately 1 min for the changes to be deployed 31 | - Access the rendered pages under your username as domain: 32 | 33 | 34 | ## Option 2: Local testing 35 | 36 | - In `docs/_config.yml`, replace the line 37 | ``` 38 | url: "https://coreos.github.io" 39 | ``` 40 | by 41 | ``` 42 | url: "http://localhost:4000" 43 | ``` 44 | - Use the following commands to install the Ruby gems and start a local 45 | development server: 46 | ``` 47 | export JEKYLL_ENV="production" 48 | bundle install --path=./vendor/gems/ 49 | bundle exec jekyll serve --livereload --strict_front_matter 50 | ``` 51 | - Access the documentaion by pointing your browser to 52 | 53 | -------------------------------------------------------------------------------- /internals/README-initramfs.md: -------------------------------------------------------------------------------- 1 | # The initramfs 2 | 3 | For CoreOS the initramfs is critical; a key technological pillar of CoreOS is [Ignition](https://github.com/coreos/ignition/) which e.g. handles partitioning disks that happen on the first boot. One way to think about this is that Ignition handles a lot of the roles that a traditional "installer" program might - our initramfs contains `sgdisk`, most others don't. 4 | 5 | # Initramfs history 6 | 7 | See the upstream Linux kernel document: ["what is initramfs"](https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html?highlight=initramfs#what-is-initramfs). 8 | 9 | It's basically a small filesystem that gets passed to the kernel by the bootloader, and the kernel unpacks and runs it. 10 | 11 | The high level goal of the initramfs is to mount the root filesystem (conventionally at `/sysroot`) and switch root into it, i.e. turning `/sysroot` into `/`. 12 | 13 | # Initramfs technologies 14 | 15 | We use [dracut](https://github.com/dracutdevs/dracut/) the same as a number of other (but not all) distributions. It basically gathers binaries/configuration from the real root and generates an initramfs from them. 16 | 17 | Modern systemd has a very clean design for both the initramfs and the real boot. See the ["man bootup"](https://www.freedesktop.org/software/systemd/man/bootup.html) documentation. The software involved implements these abstract `.target` units. 18 | 19 | There are 3 important pieces of software involved in the initramfs: 20 | - [30ignition](https://github.com/coreos/ignition/tree/main/dracut/30ignition) (Part of Ignition) 21 | - [ostree-prepare-root](https://github.com/ostreedev/ostree/blob/main/src/switchroot/ostree-prepare-root.c) (Part of OSTree) 22 | - [40ignition-ostree dracut module](https://github.com/coreos/fedora-coreos-config/tree/testing-devel/overlay.d/05core/usr/lib/dracut/modules.d/40ignition-ostree) (fedora-coreos-config) 23 | 24 | Note that Ignition and OSTree are both independent projects consumed by other distributions in addition to Fedora CoreOS. This means that we want to support using each independently. The `40ignition-ostree` dracut module *ties those two together* - it's the place where you will find systemd units that have direct ordering relationship around the two projects. 25 | 26 | # First boot versus subsequent boot 27 | 28 | Ignition runs only on the first boot. To account for this, ignition-dracut ships two targets: 29 | 30 | `ignition-complete.target`: Enabled on first boot 31 | `ignition-subsequent.target`: Enabled on every boot **except** the first 32 | 33 | `-complete` will pull in a lot of units, such as `ignition-fetch.service` and `ignition-disks.service` 34 | 35 | We implement`ignition-subsequent.target` today by hooking in `ignition-ostree-mount-subsequent-sysroot.service` which basically just waits for a filesystem with `LABEL=root` and mounts it - very simple! But see below around the root filesystem. 36 | 37 | # Images and finding filesystems 38 | 39 | An important part of the CoreOS philosophy is to make bare metal as close to cloud workflows as possible. This follows from moving all support for e.g. filesystem provisioning into Ignition. 40 | 41 | [coreos-assembler](https://github.com/coreos/coreos-assembler) generates a disk image with `boot` (`/boot`) and `root` (`/`) labels. Various components of the initramfs (as well as our default GRUB config) use the `label=boot` to find the boot partition. The label `root` is used by `ignition-ostree-mount-firstboot-sysroot.service`. 42 | 43 | # Live versus diskful 44 | 45 | We also ship a "Live" ISO/PXE image which uses a different filesystem (squashfs). This caused us to introduce a separate `ignition-diskful.target` which only runs on cases where we're booted from writable persistent storage (i.e. not ISO/PXE). 46 | 47 | To implement the "live" or "run in RAM" aspects, the `live-generator` sets up an `overlayfs` for `/etc` and a `tmpfs` for `/var`. Everything else is part of the `squashfs` which is read-only. 48 | 49 | The Live OS setup differs currently between the ISO and PXE: https://github.com/coreos/fedora-coreos-tracker/issues/390 50 | 51 | Currently when generating the ISO image we inject a label onto the root filesystem, and a `coreos.liveiso` kernel argument matching it. The initramfs knows to look for that kernel argument, which it then uses to mount the squashfs which contains the root filesystem. 52 | 53 | In contrast for PXE the squashfs is in the `live-initramfs` directly. 54 | 55 | # /boot in the initramfs 56 | 57 | There are multiple services which access the `/boot` partition in the initramfs. They are (in running order): 58 | - `coreos-ignition-setup-user.service`: mounts `/boot` read-only to look for a user Ignition config. This is the first Ignition-related service to run. 59 | - `coreos-copy-firstboot-network.service`: mounts `/boot` read-only to look for NetworkManager keyfiles. This unit runs after Ignition's `ignition-fetch-offline.service` but before networking is optionally brought up as part of `dracut-initqueue.service`. 60 | - (on RHCOS) `rhcos-fips.service`: mounts `/boot` read-write to append `fips=1` to the BLS configs and reboot if FIPS mode is requested. This unit runs after `ignition-fetch.service` but before `ignition-disks.service`. 61 | - `coreos-boot-edit.service`: mounts `/boot` read-write late in the initramfs process after `ignition-files.service` to make final edits (e.g. remove firstboot networking configuration files if necessary, append rootmap kargs to the BLS configs). 62 | 63 | # Multipath handling 64 | 65 | Currently, the way multipath is supported is to add `rd.multipath=default` and `root=/dev/disk/by-label/dm-mpath-root` to the kernel command-line. They can be added day-1 or day-2, but the former is recommended. These kargs play different roles. The `root` karg ensures that systemd-fstab-generator will wait until multipathd has assembled the device and the symlink shows up (rather than trying to mount a single path). The `rd.multipath=default` karg will cause [the multipath dracut module to generate a default configuration](https://github.com/dracutdevs/dracut/blob/ab798f6785513c33f9a71371ceea65bd782973d5/modules.d/90multipath/multipathd-configure.service#L10) that `multipathd` will then act on. 66 | 67 | Crucially, `rd.multipath` on first boot also makes us assume that the `boot` filesystem is multipathed and wait for `/dev/disk/by-label/dm-mpath-boot` to show up. As seen in the previous section, many things need access to the bootfs on first boot. But we can't do any I/O to the boot device if it's multipathed because it's undefined which of the single paths will win the `by-label/boot` race, and it may be a path that is non-optimized (see [this PR](https://github.com/coreos/fedora-coreos-config/pull/1011) and linked RHBZ for details). Instead of trying to automatically determine if the bootfs is on multipath and whether we should wait for `multipathd` to assemble it (which is subject to race conditions), we decide on whether `rd.multipath` is provided (see also [this discussion](https://github.com/coreos/fedora-coreos-config/pull/1022#discussion_r634631063)). 68 | 69 | The `dm-mpath-$label` symlinks are created by [a udev rule we ship](https://github.com/coreos/fedora-coreos-config/blob/8fc657ebb9617a1ab9f1b513123d19ea7775ac68/overlay.d/05core/usr/lib/udev/rules.d/90-coreos-device-mapper.rules#L24). 70 | 71 | # SELinux in the initramfs 72 | 73 | SELinux policy is loaded in the real root. This means that every file we create in the initramfs must be relabeled. See this code: https://github.com/coreos/fedora-coreos-config/blob/testing-devel/overlay.d/05core/usr/lib/dracut/modules.d/40ignition-ostree/coreos-relabel 74 | 75 | # Networking 76 | 77 | By default, the initramfs does not try to enable networking if it's not needed. This is important in the live ISO case. Software may request networking if they require it. For example, if Ignition detects a config which requires the network, it writes a stamp file at `/run/ignition/neednet` which we then detect and translate into `rd.neednet=1` via `coreos-enable-network.service`. For any other situation in which FCOS needs networking, we should add a triggering condition to that service. In the future if more cases are added, we may provide a cleaner API which does not require continuously expanding this list. 78 | 79 | Network *enablement* is separate from network *configuration*. Afterburn handles rendering of network kernel arguments via [`afterburn-network-kargs.service`](https://github.com/coreos/afterburn/blob/e0c46db33ece0e003d278be73f2c83e237b315d0/dracut/30afterburn/afterburn-network-kargs.service). On some platforms, it may use a backchannel to fetch the network kargs. By default, it will use `AFTERBURN_NETWORK_KARGS_DEFAULT`, which is defined in [the fedora-coreos-config repo](https://github.com/coreos/fedora-coreos-config/blob/82f22f92620b60b009e94872a7b44fade8e782e1/overlay.d/05core/usr/lib/dracut/modules.d/35coreos-network/50-afterburn-network-kargs-default.conf) to be `ip=auto`. 80 | 81 | For more details of the design, see https://github.com/coreos/fedora-coreos-tracker/issues/460 as well as the project [documentation](https://docs.fedoraproject.org/en-US/fedora-coreos/sysconfig-network-configuration/). 82 | 83 | # Reprovisioning the root 84 | 85 | A big recent effort is [reprovisioning the root filesystem](https://github.com/coreos/fedora-coreos-tracker/issues/94). This will make the "subsequent" boot path work differently based on configuration. 86 | 87 | # Debugging the initramfs 88 | 89 | - https://fedoraproject.org/wiki/How_to_debug_Dracut_problems is generally useful 90 | - Use `cosa buildinitramfs-fast` for fast iteration: https://github.com/coreos/coreos-assembler/pull/1433 91 | - ignition-dracut contains code to dump the journal to a virtio channel: https://github.com/coreos/ignition-dracut/pull/146 - This is used by parts of coreos-assembler 92 | -------------------------------------------------------------------------------- /internals/README-internals.md: -------------------------------------------------------------------------------- 1 | # CoreOS Internals docs 2 | 3 | This document intends to be a dumping ground to briefly describe various problem domains we've hit around building/delivering/testing CoreOS style systems. 4 | 5 | Other important links: 6 | 7 | - https://github.com/coreos/coreos-assembler/ 8 | - https://github.com/coreos/fedora-coreos-config 9 | 10 | # Initramfs 11 | 12 | This topic is big enough to have its own document: [README-initramfs.md](README-initramfs.md). 13 | 14 | # CPU microcode 15 | 16 | rpm-ostree runs dracut on the server side, and dracut knows how to pick up CPU microcode and prepend it to the initramfs. Relevant bugs: 17 | 18 | - https://bugzilla.redhat.com/show_bug.cgi?id=1199582 19 | - https://bugzilla.redhat.com/show_bug.cgi?id=1803883 20 | 21 | # Entropy 22 | 23 | As of recently we enable `CONFIG_RANDOM_TRUST_CPU` which covers modern `x86_64` systems for example. 24 | 25 | - https://bugzilla.redhat.com/show_bug.cgi?id=1830280 26 | - https://github.com/openshift/machine-config-operator/issues/854 27 | 28 | # Networking 29 | 30 | In [this tracker issue](https://github.com/coreos/fedora-coreos-tracker/issues/24) a decision was made to use NetworkManager. As of recently we use NetworkManager in the initramfs. And even more recently, things have been reworked so that [afterburn can control initramfs networking](https://github.com/coreos/afterburn/pull/404) on specific clouds. 31 | 32 | # Time synchronization 33 | 34 | We use chrony, with some [additional custom logic for specific clouds](https://github.com/coreos/fedora-coreos-config/blob/faf387eac89d14924a1e2021d2093d0cdb8af8b3/overlay.d/20platform-chrony/usr/lib/systemd/system-generators/coreos-platform-chrony). 35 | See also DHCP propagation: https://github.com/coreos/fedora-coreos-config/pull/412 36 | 37 | # Aleph version 38 | 39 | `rpm-ostree status` will show admins the state of the ostree, but a few things live outside that and are not subject to in place updates. For example, the on-disk filesystem (default `xfs`) and its specific layout, as well as the bootloader. 40 | 41 | See [this pull request](https://github.com/coreos/coreos-assembler/pull/768/commits/2701e91838e18d3eac0694fd0a5f003befcfb218) which added `/sysroot/.coreos-aleph-version.json` that can be used to track the version of that data. 42 | 43 | # ignition.platform.id 44 | 45 | See https://docs.fedoraproject.org/en-US/fedora-coreos/platforms/ 46 | 47 | The design we have today is that each CoreOS system is the same OS content - the same OSTree commit, 48 | and beyond that the exact same bootloader version, etc. 49 | 50 | There are differences per platform on the image formats (VHD versus qcow2 vs raw, etc). However, 51 | what's *inside* the disk image for each platform is almost the same. 52 | 53 | A key difference between each image is the `ignition.platform.id` kernel argument. From the 54 | moment the system boots and the kernel loads the initramfs, our userspace code uses this 55 | to reliably know its target platform. As could be guessed from the name, [https://github.com/coreos/ignition/](ignition) 56 | uses this, and it runs early on. 57 | 58 | But there's other code which dynamically dispatches on the platform ID: 59 | 60 | - https://github.com/coreos/afterburn/ 61 | - [The time sync setup code](https://github.com/coreos/fedora-coreos-config/blob/d87b52bc6a90b53e1afeab2731b52612d5e3bbc0/tests/kola/chrony/coreos-platform-chrony-generator#L9) 62 | - [network requirement detection](https://github.com/coreos/fedora-coreos-config/blob/d87b52bc6a90b53e1afeab2731b52612d5e3bbc0/overlay.d/05core/usr/lib/dracut/modules.d/35coreos-network/coreos-enable-network.service#L13) 63 | 64 | Notice in particular how the time synchronization code ends up reconfiguring chrony dynamically. 65 | For other operating systems which do "per cloud" disk images, it would have been more 66 | natural to just change `/etc/chrony.conf` per platform. But that would mean we have a different 67 | ostree commit checksum per platform, breaking our "image based" update model. 68 | 69 | # Multipath 70 | 71 | Multipath differs from other storage configurations by a major aspect: it is usually not 72 | configured by Ignition. If we mount an individual path for e.g. `/sysroot`, multipathd will 73 | not be able to take ownership afterwards. Furthermore, directly accessing individual paths 74 | before `multipathd` takes over is unsafe (e.g. it could be a non-optimized path). And since 75 | we need to mount `/boot` very early on, this naturally pushes multipath configuration into 76 | kernel arguments (and ideally soon, initramfs overlays). 77 | 78 | What we ended up with is adding an `rd.multipath=default` kernel argument which 79 | triggers dracut to do "basic" automatic multipath setup in the stock initramfs: 80 | https://github.com/dracutdevs/dracut/pull/780 81 | 82 | By the nature of multipath, a tricky aspect is that e.g. the `by-label/root` symlink is 83 | valid both *before* and *after* multipathd takes ownership. In order to safely wait for the 84 | multipathed rootfs to show up, we have these udev rules which create, for example, 85 | `by-label/dm-mpath-root`: 86 | 87 | https://github.com/coreos/fedora-coreos-config/blob/94e0daa567a658f023d48ac5929c72ed910792bd/overlay.d/05core/usr/lib/udev/rules.d/90-coreos-device-mapper.rules#L1 88 | 89 | This is why we require the `root=/dev/disk/by-label/dm-mpath-root` kernel argument; so that 90 | the mount generated by `systemd-fstab-generator` waits for the the multipath version to show 91 | up and doesn't just mount an individual path. 92 | 93 | Firstboot (day-1) support is usually done at coreos-installer time by doing: 94 | 95 | ``` 96 | coreos-installer install \ 97 | --append-karg rd.multipath=default \ 98 | --append-karg root=/dev/disk/by-label/dm-mpath-root \ 99 | --append-karg rw 100 | ... 101 | ``` 102 | 103 | The `rw` bit is necessary because `systemd-fstab-generator` will create a read-only mount by 104 | default (usually, `rw` is injected by `rdcore rootmap` for subsequent boots, but this does 105 | not happen if there is already a `root` karg). 106 | 107 | That said, turning on multipath on a subsequent (day-2) boot is still supported if the 108 | multipath setup itself is compatible with this. This is done by appending the same kargs as 109 | above using e.g. `rpm-ostree kargs`. (Appending the kargs can also be done via 110 | `ignition-kargs`, though this still counts as "day-2" since on first boot we'd still access 111 | the boot partition directly.) 112 | 113 | We don't yet document multipath for FCOS, but we do document this setup for 114 | OpenShift that has a kola test: 115 | 116 | - https://github.com/coreos/coreos-assembler/blob/f5d003d2ebb81283c3e071ce2ac268884aa7232b/mantle/kola/tests/misc/multipath.go 117 | 118 | We also support multipath on an individual non-root partition. See the test above for how 119 | this works. 120 | 121 | More links: 122 | 123 | - https://github.com/coreos/ignition-dracut/issues/154 124 | - https://bugzilla.redhat.com/show_bug.cgi?id=1944660 125 | - https://github.com/coreos/fedora-coreos-config/pull/1011 126 | -------------------------------------------------------------------------------- /meeting-people.txt: -------------------------------------------------------------------------------- 1 | # List of people to ping before the Fedora CoreOS community meetings. 2 | # Please keep this list in alphabetical order. 3 | @aaradhak:matrix.org 4 | @apiaseck:matrix.org 5 | @bipinbn:fedora.im 6 | @bri:transfem.dev 7 | @davdunc:fedora.im 8 | @dustymabe:matrix.org 9 | @guidon:guidon.ems.host 10 | @gurssing:matrix.org 11 | @jaimelm:fedora.im 12 | @jbrooks:matrix.org 13 | @jbtrystram:matrix.org 14 | @jdoss:fedora.im 15 | @jlebon:fedora.im 16 | @jmarrero:matrix.org 17 | @lorbus:matrix.org 18 | @marmijo:fedora.im 19 | @miabbott:fedora.im 20 | @quentin9696:matrix.org 21 | @ravanelli:fedora.im 22 | @tlbueno:fedora.im 23 | @walters:fedora.im 24 | @ydesouza:fedora.im 25 | @yves:siegrist.io 26 | -------------------------------------------------------------------------------- /metadata/README.md: -------------------------------------------------------------------------------- 1 | # Fedora CoreOS metadata 2 | 3 | Fedora CoreOS artifacts and streams are described by metadata objects, in the form of JSON documents. 4 | This allows the general audience to consume releases and updates in a machine-friendly way. 5 | 6 | The following types of metadata exist: 7 | * stream metadata 8 | * updates metadata 9 | * release index 10 | * release metadata 11 | * coreos-assembler builds 12 | 13 | ## Stream metadata 14 | 15 | This document contains details about latest available artifacts, on each stream. 16 | 17 | * URL: `https://builds.coreos.fedoraproject.org/streams/${stream}.json` 18 | * Usage: Primary entrypoint for users. Documented at https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started/ 19 | and e.g. consumed by the [getfedora.org download page](https://getfedora.org/en/coreos/download/) 20 | * (TODO) stream metadata JSON schema 21 | * [stream metadata sample][stream-sample] 22 | * [comments and rationale][stream-rationale] 23 | 24 | [stream-sample]: ./stream/sample.json 25 | [stream-rationale]: ./stream/rationale.yaml 26 | 27 | Projects/Code: 28 | 29 | - https://github.com/coreos/stream-metadata-go 30 | - https://github.com/coreos/fedora-coreos-stream-generator/ 31 | 32 | ## Updates metadata 33 | 34 | This document contains details about updates and rollouts, on each stream. 35 | 36 | * URL: `https://builds.coreos.fedoraproject.org/updates/${stream}.json` 37 | * Usage: consumed by Cincinnati to discover valid update-paths 38 | * [JSON document specifications][updates-specs] 39 | * [updates metadata JSON schema][updates-schema] 40 | * [updates metadata sample][updates-sample] 41 | 42 | [updates-schema]: ./updates/fcos-updates-schema.json 43 | [updates-sample]: ./updates/sample.json 44 | [updates-specs]: ./updates/specifications.md 45 | 46 | ## Release-index 47 | 48 | This piece of metadata is meant to list all existing releases, on each stream. 49 | 50 | * URL: `https://builds.coreos.fedoraproject.org/prod/streams/${stream}/releases.json` 51 | * Usage: consumed by Cincinnati to discover valid releases 52 | * [JSON document specifications][release-index-specs] 53 | * [release-index JSON schema][release-index-schema] 54 | * [release-index sample][release-index-sample] 55 | 56 | [release-index-schema]: ./release-index/fcos-release-index-schema.json 57 | [release-index-sample]: ./release-index/sample.json 58 | [release-index-specs]: ./release-index/specifications.md 59 | 60 | Projects/Code: 61 | 62 | - https://github.com/coreos/coreos-assembler/blob/main/mantle/cmd/plume/release.go 63 | 64 | ## Release metadata 65 | 66 | This document contains details about artifacts belonging to each release. 67 | 68 | * URL: dynamic for each release, provided by the release-index 69 | * Usage: internal tooling, artifacts mirroring, auditing 70 | * (TODO) release metadata JSON schema 71 | * [release metadata sample][release-sample] 72 | 73 | [release-sample]: ./release/sample.json 74 | 75 | ## CoreOS Assembler builds 76 | 77 | This is the primary artifact of coreos-assembler, which turns 78 | RPMs and our configuration into images and ostree commits. 79 | 80 | Projects: 81 | 82 | - https://github.com/coreos/coreos-assembler 83 | -------------------------------------------------------------------------------- /metadata/release-index/fcos-release-index-schema.json: -------------------------------------------------------------------------------- 1 | { 2 | "definitions": {}, 3 | "$schema": "http://json-schema.org/draft-07/schema#", 4 | "type": "object", 5 | "title": "release-index", 6 | "description": "FCOS release-index JSON document.", 7 | "required": [ 8 | "releases", 9 | "metadata", 10 | "stream" 11 | ], 12 | "properties": { 13 | "note": { 14 | "type": "string", 15 | "description": "human-friendly documentation text" 16 | }, 17 | "releases": { 18 | "type": "array", 19 | "description": "Each entry MUST have a unique non-empty version field. The list MUST be sorted in ascending order, from oldest to latest release.", 20 | "items": { 21 | "type": "object", 22 | "description": "Release entry.", 23 | "required": [ 24 | "commits", 25 | "version", 26 | "metadata" 27 | ], 28 | "properties": { 29 | "commits": { 30 | "type": "array", 31 | "title": "OSTree commits", 32 | "description": "Release entries. Each entry MUST have a unique non-empty architecture field.", 33 | "items": { 34 | "type": "object", 35 | "title": "commit entry", 36 | "required": [ 37 | "architecture", 38 | "checksum" 39 | ], 40 | "properties": { 41 | "architecture": { 42 | "type": "string", 43 | "title": "architecture", 44 | "description": "Relevant base-architecture for this commit." 45 | }, 46 | "checksum": { 47 | "type": "string", 48 | "title": "checksum", 49 | "description": "OSTree commit identifier." 50 | } 51 | } 52 | } 53 | }, 54 | "version": { 55 | "type": "string", 56 | "title": "release version", 57 | "description": "Release version." 58 | }, 59 | "metadata": { 60 | "type": "string", 61 | "title": "metadata URL", 62 | "description": "URL to the release metadata document for this version." 63 | } 64 | } 65 | } 66 | }, 67 | "metadata": { 68 | "type": "object", 69 | "title": "document metadata", 70 | "description": "Metadata for this JSON document.", 71 | "required": [ 72 | "last-modified" 73 | ], 74 | "properties": { 75 | "last-modified": { 76 | "type": "string", 77 | "title": "last change timestamp", 78 | "description": "UTC timestamp for the last change, in ISO 8601 format." 79 | } 80 | } 81 | }, 82 | "stream": { 83 | "type": "string", 84 | "description": "Name of the release stream." 85 | } 86 | } 87 | } 88 | -------------------------------------------------------------------------------- /metadata/release-index/sample.json: -------------------------------------------------------------------------------- 1 | { 2 | "note": "For use only by Fedora CoreOS internal tooling. All other applications should obtain release info from stream metadata endpoints.", 3 | "releases": [ 4 | { 5 | "commits": [ 6 | { 7 | "architecture": "x86_64", 8 | "checksum": "a9c8d66d3628d1b9b4c4690777e8b730d08329b4359410cb410a2003296af1ca" 9 | } 10 | ], 11 | "version": "30.20190801.0", 12 | "metadata": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/release.json" 13 | }, 14 | { 15 | "commits": [ 16 | { 17 | "architecture": "x86_64", 18 | "checksum": "b4beca154dab3696fd04f32ddab818102caa9247ec3192403adb9aaecc991bd9" 19 | } 20 | ], 21 | "version": "30.20190905.0", 22 | "metadata": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190905.0/release.json" 23 | } 24 | ], 25 | "metadata": { 26 | "last-modified": "2019-09-06T15:56:00Z" 27 | }, 28 | "stream": "testing" 29 | } 30 | -------------------------------------------------------------------------------- /metadata/release-index/specifications.md: -------------------------------------------------------------------------------- 1 | # Release-index specifications 2 | 3 | The release-index is a JSON document with a single object containing the following fields: 4 | 5 | - `note` (optional, string): a human-friendly documentation text. 6 | - `stream` (mandatory, string): name of the release stream. 7 | - `metadata` (mandatory, object): metadata attributes for this JSON document. 8 | - `last-modified` (mandatory, string): UTC timestamp for the last change, in ISO 8601 format. 9 | - `releases` (mandatory, list of objects): per-release details. Each entry MUST have a unique non-empty `version` field. The list MUST be sorted in ascending order, from oldest to latest release. 10 | - `version` (mandatory, string): release version identifier. 11 | - `metadata` (mandatory, string): URL to the release metadata document for this version. 12 | - `commits` (mandatory, list of objects): per-architecture OSTree commits. Each entry MUST have a unique non-empty `architecture` field. 13 | - `architecture` (mandatory, string): relevant base-architecture for this commit. 14 | - `checksum` (mandatory, string): OSTree commit identifier. 15 | -------------------------------------------------------------------------------- /metadata/release/sample.json: -------------------------------------------------------------------------------- 1 | { 2 | "release": "30.20190801.0", 3 | "stream": "testing", 4 | "architectures": { 5 | "x86_64": { 6 | "media": { 7 | "aliyun": { 8 | "artifacts": { 9 | "qcow2.xz": { 10 | "disk": { 11 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-aliyun.qcow2.xz", 12 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-aliyun.qcow2.xz.sig", 13 | "sha256": "8f1492f1e9e94ec3f3ecef188c4a2da52348c4b830f6365181bd03e1d969f161" 14 | } 15 | } 16 | }, 17 | "images": { 18 | "us-east-1": { 19 | "image": "m-6wedcb2rfmhkcl2bsbz5" 20 | } 21 | } 22 | }, 23 | "aws": { 24 | "artifacts": { 25 | "vmdk.xz": { 26 | "disk": { 27 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-aws.vmdk.xz", 28 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-aws.vmdk.xz.sig", 29 | "sha256": "7afd8ebdd61ccb6da45dfb19ccc71c47f43e1189c1fb7eb75df6f23d7c8f87dc" 30 | } 31 | } 32 | }, 33 | "images": { 34 | "us-east-1": { 35 | "image": "ami-0506465824cb1b578" 36 | } 37 | } 38 | }, 39 | "applehv": { 40 | "artifacts": { 41 | "raw.gz": { 42 | "disk": { 43 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-applehv.raw.gz", 44 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-applehv.raw.gz.sig", 45 | "sha256": "a889159d661339e635372b807f0a98bb93c64aabfaf89a801b2f03491488f0ef" 46 | } 47 | } 48 | } 49 | }, 50 | "azure": { 51 | "artifacts": { 52 | "vhd.xz": { 53 | "disk": { 54 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-azure.vhd.xz", 55 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-azure.vhd.xz.sig", 56 | "sha256": "4bb0e1595f66f344c1cc084e163c4352235b2accf3a1385b9eb4b3e4ca5b1d24" 57 | } 58 | } 59 | } 60 | }, 61 | "azurestack": { 62 | "artifacts": { 63 | "vhd.xz": { 64 | "disk": { 65 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-azurestack.vhd.xz", 66 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-azurestack.vhd.xz.sig", 67 | "sha256": "344c1cc084e163c4352235b2accf34d24bb0e1595f66fa1385b9eb4b3e4ca5b1" 68 | } 69 | } 70 | } 71 | }, 72 | "digitalocean": { 73 | "artifacts": { 74 | "qcow2.gz": { 75 | "disk": { 76 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-digitalocean.qcow2.gz", 77 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-digitalocean.qcow2.gz.sig", 78 | "sha256": "435224bb0e1595f344c1cc05b1d2484e163c66f35b2accf3a1385b9eb4b3e4ca" 79 | } 80 | } 81 | } 82 | }, 83 | "exoscale": { 84 | "artifacts": { 85 | "qcow2.xz": { 86 | "disk": { 87 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-exoscale.qcow2.xz", 88 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-exoscale.qcow2.xz.sig", 89 | "sha256": "435224bb0e1595f344c1cc05b1d2484e163c66f35b2accf3a1385b9eb4b3e4ca" 90 | } 91 | } 92 | } 93 | }, 94 | "gcp": { 95 | "artifacts": { 96 | "tar.gz": { 97 | "disk": { 98 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-gcp.tar.gz", 99 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-gcp.tar.gz.sig", 100 | "sha256": "344c1cc05b1d2484e163c66f35b2accf3a1385b9eb435224bb0e1595f4b3e4ca" 101 | } 102 | } 103 | } 104 | }, 105 | "hetzner": { 106 | "artifacts": { 107 | "raw.xz": { 108 | "disk": { 109 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-hetzner.raw.xz", 110 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-hetzner.raw.xz.sig", 111 | "sha256": "a889159d661339e635372b807f0a98bb93c64aabfaf89a801b2f03491488f0ef" 112 | } 113 | } 114 | } 115 | }, 116 | "hyperv": { 117 | "artifacts": { 118 | "vhdx.zip": { 119 | "disk": { 120 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-hyperv.vhdx.zip", 121 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-hyperv.vhdx.zip.sig", 122 | "sha256": "a889159d661339e635372b807f0a98bb93c64aabfaf89a801b2f03491488f0ef" 123 | } 124 | } 125 | } 126 | }, 127 | "ibmcloud": { 128 | "artifacts": { 129 | "qcow2.xz": { 130 | "disk": { 131 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-ibmcloud.qcow2.xz", 132 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-ibmcloud.qcow2.xz.sig", 133 | "sha256": "344c1cc05b1d2484e163c66f35b2accf3a1385b9eb435224bb0e1595f4b3e4ca" 134 | } 135 | } 136 | } 137 | }, 138 | "kubevirt": { 139 | "artifacts": { 140 | "ociarchive": { 141 | "disk": { 142 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-kubevirt.ociarchive", 143 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-kubevirt.ociarchive.sig", 144 | "sha256": "2accf3a1385b9eb435224bb0e1595f4b3e4344c1cc05b1d2484e163c66f35bca" 145 | } 146 | } 147 | } 148 | }, 149 | "metal": { 150 | "artifacts": { 151 | "raw.xz": { 152 | "disk": { 153 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-metal.raw.xz", 154 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-metal.raw.xz.sig", 155 | "sha256": "881178a4794816e623b02012a84b11d59a96dd59035508a0986a5b6c6be074ed" 156 | } 157 | }, 158 | "iso": { 159 | "disk": { 160 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-live.iso", 161 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-live.iso.sig", 162 | "sha256": "aab20fcafc240fa03f7e43370f8be8c14b99b045eca156a0f5e77286b2e9e8c4" 163 | } 164 | }, 165 | "pxe": { 166 | "kernel": { 167 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-live-kernel", 168 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-live-kernel.sig", 169 | "sha256": "bb493370b3716a009628197b7fce41107f1f5349f1a7ef67a8ecc7eebb3d2183" 170 | }, 171 | "initramfs": { 172 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-live-initramfs.img", 173 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-live-initramfs.img.sig", 174 | "sha256": "04dde273b9e5d1b361beb44fde337f915509ad8e128fb408f793fdd0ae84c17d" 175 | }, 176 | "rootfs": { 177 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-live-rootfs.img", 178 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-live-rootfs.img.sig", 179 | "sha256": "509ad8e128fb408f793fdd0ae84c17d04dde273b9e5d1b361beb44fde337f915" 180 | } 181 | } 182 | } 183 | }, 184 | "nutanix": { 185 | "artifacts": { 186 | "qcow2": { 187 | "disk": { 188 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-nutanix.qcow2", 189 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-nutanix.qcow2.sig", 190 | "sha256": "1b3e4ca5b1d2463c4352235b2accf95f66f344c1cc084e3a1385b9eb4bb0e154" 191 | } 192 | } 193 | } 194 | }, 195 | "openstack": { 196 | "artifacts": { 197 | "qcow2.xz": { 198 | "disk": { 199 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-openstack.qcow2.xz", 200 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-openstack.qcow2.xz.sig", 201 | "sha256": "b2cab76cb2038826cb8de99f34d192bda4e805a4eb51be2979ba984424e72501" 202 | } 203 | } 204 | } 205 | }, 206 | "qemu": { 207 | "artifacts": { 208 | "qcow2.xz": { 209 | "disk": { 210 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-qemu.qcow2.xz", 211 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-qemu.qcow2.xz.sig", 212 | "sha256": "4dcc04bd43f48bc74a16bd7d20b47829591a2a2fbe3ee8d59fedef2b1ddd1264" 213 | } 214 | } 215 | } 216 | }, 217 | "qemu-secex": { 218 | "artifacts": { 219 | "qcow2.xz": { 220 | "disk": { 221 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-qemu-secex.qcow2.xz", 222 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-qemu-secex.qcow2.xz.sig", 223 | "sha256": "2afbb0ac4a19f58a55db35db0a690d488f065664e9bcba1b802966f0ae6aad57" 224 | } 225 | } 226 | } 227 | }, 228 | "virtualbox": { 229 | "artifacts": { 230 | "ova": { 231 | "disk": { 232 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-virtualbox.ova", 233 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-virtualbox.ova.sig", 234 | "sha256": "54729f458c1552c19aa2f2b905860fadbe0a714df45d1d49731725038895094c" 235 | } 236 | } 237 | } 238 | }, 239 | "vmware": { 240 | "artifacts": { 241 | "ova": { 242 | "disk": { 243 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-vmware.ova", 244 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-vmware.ova.sig", 245 | "sha256": "b905860fadbe0a754729f458c1552c19aa2f214df45d1d49731725038895094c" 246 | } 247 | } 248 | } 249 | }, 250 | "vultr": { 251 | "artifacts": { 252 | "raw.xz": { 253 | "disk": { 254 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-vultr.raw.xz", 255 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20190801.0/x86_64/fedora-coreos-30.20190801.0-vultr.raw.xz.sig", 256 | "sha256": "d7d20b47829591a2a2fbe3ee8d59fe4dcc04bd43f48bc74a16bdef2b1ddd1264" 257 | } 258 | } 259 | } 260 | } 261 | }, 262 | "commit": "a9c8d66d3628d1b9b4c4690777e8b730d08329b4359410cb410a2003296af1ca" 263 | } 264 | } 265 | } 266 | -------------------------------------------------------------------------------- /metadata/stream/rationale.yaml: -------------------------------------------------------------------------------- 1 | # Note: the actual document will be JSON 2 | 3 | # Include stream name so the document is self-contained 4 | stream: stable 5 | metadata: 6 | last-modified: "2019-06-04T16:18:34Z" 7 | generator: "fedora-coreos-stream-generator v0.1.0" 8 | architectures: 9 | x86_64: 10 | artifacts: 11 | # Some of these will be useful for many users, such as qemu or 12 | # openstack. Some will likely only be useful for cloud operators, 13 | # such as digitalocean or packet. Some, such as aws, are useful 14 | # for users in special situations. 15 | aliyun: 16 | release: 30.1.2.3 17 | formats: 18 | "qcow2.xz": 19 | disk: 20 | location: https://artifacts.example.com/g0xah6aenvaaVosh.qcow2.xz 21 | signature: https://artifacts.example.com/g0xah6aenvaaVosh.qcow2.xz.sig 22 | sha256: 149afbf4c8996fb92427ae3b0c44298fc1ce41e4649b934ca495991b7852b855 23 | uncompressed-sha256: d02d5ac0f2a2789602e9df950c38acb15380d2799b4bdb59394e4eeabdd3a662 24 | applehv: 25 | release: 30.1.2.3 26 | formats: 27 | "raw.gz": 28 | disk: 29 | location: https://artifacts.example.com/quohgh8ei0uzaD5a.raw.gz 30 | signature: https://artifacts.example.com/quohgh8ei0uzaD5a.raw.gz.sig 31 | sha256: 4c8996fb92427ae41e4649b934ca4e3b0c44298fc1c149afbf95991b7852b855 32 | aws: 33 | release: 30.1.2.3 34 | formats: 35 | # Generally one format per platform, but allow for future expansion 36 | # without obscuring the platform ID (as on Container Linux) 37 | "vmdk.xz": 38 | # Generally only one artifact, but not always 39 | disk: 40 | location: https://artifacts.example.com/dsB2fnzP7KhqzQ5a.vmdk.xz 41 | signature: https://artifacts.example.com/dsB2fnzP7KhqzQ5a.vmdk.xz.sig 42 | sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 43 | uncompressed-sha256: 38acb15d02d5ac0f2a2789602e9df950c380d2799b4bdb59394e4eeabdd3a662 44 | azure: 45 | release: 30.1.2.3 46 | formats: 47 | "vhd.xz": 48 | disk: 49 | location: https://artifacts.example.com/6vaaVoshaeng0xah.vhd.xz 50 | signature: https://artifacts.example.com/6vaaVoshaeng0xah.vhd.xz.sig 51 | sha256: f4c8996fb92427ae41e4e3b0c44298fc1c149afb649b934ca495991b7852b855 52 | uncompressed-sha256: 38acb15d02d5ac0f2a2789602e9df950c380d2799b4bdb59394e4eeabdd3a662 53 | azurestack: 54 | release: 30.1.2.3 55 | formats: 56 | "vhd.xz": 57 | disk: 58 | location: https://artifacts.example.com/ng0xahos6aevaaVh.vhd.xz 59 | signature: https://artifacts.example.com/ng0xahos6aevaaVh.vhd.xz.sig 60 | sha256: ae41e4649b934ca495991b7852b855e3b0c44298fc1c149afbf4c8996fb92427 61 | uncompressed-sha256: 38acb15d02d5ac0f2a2789602e9df950c380d2799b4bdb59394e4eeabdd3a662 62 | digitalocean: 63 | release: 30.1.2.3 64 | formats: 65 | "qcow2.gz": 66 | disk: 67 | location: https://artifacts.example.com/ichaloomuHax9ahR.qcow2.gz 68 | signature: https://artifacts.example.com/ichaloomuHax9ahR.qcow2.gz.sig 69 | sha256: 427ae41e4649b934ca495991b7852b855e3b0c44298fc1c149afbf4c8996fb92 70 | uncompressed-sha256: 38acb15d02d5ac0f2a2789602e9df950c380d2799b4bdb59394e4eeabdd3a662 71 | exoscale: 72 | release: 30.1.2.3 73 | formats: 74 | "qcow2.xz": 75 | disk: 76 | location: https://artifacts.example.com/aeng0xah6vaaVosh.qcow2.xz 77 | signature: https://artifacts.example.com/aeng0xah6vaaVosh.qcow2.xz.sig 78 | sha256: 49afbf4c8996fb92427ae41e464e3b0c44298fc1c19b934ca495991b7852b855 79 | uncompressed-sha256: f2a2789602e9df950c380d2738acb15d02d5ac099b4bdb59394e4eeabdd3a662 80 | gcp: 81 | release: 30.1.2.3 82 | formats: 83 | "tar.gz": 84 | disk: 85 | location: https://artifacts.example.com/ais7tah1aa7Ahvei.tar.gz 86 | signature: https://artifacts.example.com/ais7tah1aa7Ahvei.tar.gz.sig 87 | sha256: 96fb92427ae41e4649b934ca495991b7852b85e3b0c44298fc1c149afbf4c895 88 | uncompressed-sha256: 38acb15d02d5ac0f2a2789602e9df950c380d2799b4bdb59394e4eeabdd3a662 89 | hetzner: 90 | release: 30.1.2.3 91 | formats: 92 | "raw.xz": 93 | disk: 94 | location: https://artifacts.example.com/quohgh8ei0uzaD5a.raw.xz 95 | signature: https://artifacts.example.com/quohgh8ei0uzaD5a.raw.xz.sig 96 | sha256: 4c8996fb92427ae41e4649b934ca4e3b0c44298fc1c149afbf95991b7852b855 97 | hyperv: 98 | release: 30.1.2.3 99 | formats: 100 | "vhdx.zip": 101 | disk: 102 | location: https://artifacts.example.com/quohgh8ei0uzaD5a.vhdx.zip 103 | signature: https://artifacts.example.com/quohgh8ei0uzaD5a.vhdx.zip.sig 104 | sha256: 4c8996fb92427ae41e4649b934ca4e3b0c44298fc1c149afbf95991b7852b855 105 | ibmcloud: 106 | release: 30.1.2.3 107 | formats: 108 | "qcow2.xz": 109 | disk: 110 | location: https://artifacts.example.com/0xah6vaaenVoshga.qcow2.xz 111 | signature: https://artifacts.example.com/0xah6vaaenVoshga.qcow2.xz.sig 112 | sha256: ae3b0c44298fc1ce41e4649b149afbf4c8996fb92427934ca495991b7852b855 113 | uncompressed-sha256: 02e9df950c38acb1538d02d5ac0f2a278960d2799b4bdb59394e4eeabdd3a662 114 | kubevirt: 115 | release: 30.1.2.3 116 | formats: 117 | "ociarchive": 118 | disk: 119 | location: https://artifacts.example.com/Kiejeeb6ohpu8Eel.ociarchive 120 | signature: https://artifacts.example.com/Kiejeeb6ohpu8Eel.ociarchive.sig 121 | sha256: 2427ae41e4649b934ca495991b7852b85e3b0c44298fc1c149afbf4c8996fb95 122 | metal: 123 | release: 30.1.2.3 124 | formats: 125 | "raw.xz": 126 | disk: 127 | location: https://artifacts.example.com/xTqYJZKCPNvoNs6B.raw.xz 128 | signature: https://artifacts.example.com/xTqYJZKCPNvoNs6B.raw.xz.sig 129 | sha256: 6fb92427ae41e4649b934ca49e3b0c44298fc1c149afbf4c8995991b7852b855 130 | uncompressed-sha256: 38acb15d02d5ac0f2a2789602e9df950c380d2799b4bdb59394e4eeabdd3a662 131 | iso: 132 | disk: 133 | location: https://artifacts.example.com/ADE5GO3bjAXeDcLO.iso 134 | signature: https://artifacts.example.com/ADE5GO3bjAXeDcLO.iso.sig 135 | sha256: 8996fb92427ae41e4649b934ca495991b78e3b0c44298fc1c149afbf4c52b855 136 | pxe: 137 | kernel: 138 | location: https://artifacts.example.com/hkIj8FkCydT3lV9h 139 | signature: https://artifacts.example.com/hkIj8FkCydT3lV9h.sig 140 | sha256: 27ae41e4649b934ca495991b7852be3b0c44298fc1c149afbf4c8996fb924855 141 | initramfs: 142 | location: https://artifacts.example.com/a9ytS8yB4cGZpca1.img 143 | signature: https://artifacts.example.com/a9ytS8yB4cGZpca1.img.sig 144 | sha256: ae41e4649b934ca495991b7852be3b0c44298fc1c149afbf4c8996fb92427855 145 | rootfs: 146 | location: https://artifacts.example.com/Seb8em4QU9p6wEFr.img 147 | signature: https://artifacts.example.com/Seb8em4QU9p6wEFr.img.sig 148 | sha256: fb92427ae41e4649b93e3b0c44298fc1c149afbf4c89964ca495991b7852b855 149 | nutanix: 150 | release: 30.1.2.3 151 | formats: 152 | "qcow2": 153 | disk: 154 | location: https://artifacts.example.com/xah6vaaVaeng0osh.qcow2 155 | signature: https://artifacts.example.com/xah6vaaVaeng0osh.qcow2.sig 156 | sha256: 991b7852b85b0c44298fc1c149afbfe36fb92427ae41e4649b934ca4954c8995 157 | openstack: 158 | release: 30.1.2.3 159 | formats: 160 | "qcow2.xz": 161 | disk: 162 | location: https://artifacts.example.com/oKooheogobofai8l.qcow2.xz 163 | signature: https://artifacts.example.com/oKooheogobofai8l.qcow2.xz.sig 164 | sha256: ae41e4649b934ca495991b785e3b0c44298fc1c149afbf4c8996fb924272b855 165 | uncompressed-sha256: 38acb15d02d5ac0f2a2789602e9df950c380d2799b4bdb59394e4eeabdd3a662 166 | packet: 167 | release: 30.1.2.3 168 | formats: 169 | "raw.xz": 170 | disk: 171 | location: https://artifacts.example.com/Oofohng0xo2phai5.raw.xz 172 | signature: https://artifacts.example.com/Oofohng0xo2phai5.raw.xz.sig 173 | sha256: e41e4649b934ca495991b7852b85e3b0c44298fc1c149afbf4c8996fb92427a5 174 | uncompressed-sha256: 38acb15d02d5ac0f2a2789602e9df950c380d2799b4bdb59394e4eeabdd3a662 175 | qemu: 176 | release: 30.1.2.3 177 | formats: 178 | "qcow2.xz": 179 | disk: 180 | location: https://artifacts.example.com/Siejeeb6ohpu8Eel.qcow2.xz 181 | signature: https://artifacts.example.com/Siejeeb6ohpu8Eel.qcow2.xz.sig 182 | sha256: b0c44298fc1c149afbf4c8996fb9242e37ae41e4649991b7852b855b934ca495 183 | uncompressed-sha256: 38acb15d02d5ac0f2a2789602e9df950c380d2799b4bdb59394e4eeabdd3a662 184 | qemu-secex: 185 | release: 30.1.2.3 186 | formats: 187 | "qcow2.xz": 188 | disk: 189 | location: https://artifacts.example.com/6d5814250381013f.qcow2.xz 190 | signature: https://artifacts.example.com/6d5814250381013f.qcow2.xz.sig 191 | sha256: 2afbb0ac4a19f58a55db35db0a690d488f065664e9bcba1b802966f0ae6aad57 192 | uncompressed-sha256: 2b1cb667f3468ef7b462e5ec8395fcd2982e424d1727336e95f74c611d8bbd53 193 | virtualbox: 194 | release: 30.1.2.3 195 | formats: 196 | ova: 197 | disk: 198 | location: https://artifacts.example.com/quohgh8ei0uzaD5a.ova 199 | signature: https://artifacts.example.com/quohgh8ei0uzaD5a.ova.sig 200 | sha256: 4c8996fb92427ae41e4649b934ca4e3b0c44298fc1c149afbf95991b7852b855 201 | vmware: 202 | release: 30.1.2.3 203 | formats: 204 | ova: 205 | disk: 206 | location: https://artifacts.example.com/quohgh8ei0uzaD5a.ova 207 | signature: https://artifacts.example.com/quohgh8ei0uzaD5a.ova.sig 208 | sha256: 96fb92427ae41e4649b934cae3b0c44298fc1c149afbf4c89495991b7852b855 209 | vultr: 210 | release: 30.1.2.3 211 | formats: 212 | "raw.xz": 213 | disk: 214 | location: https://artifacts.example.com/ah6vaaVaeng0xosh.raw.xz 215 | signature: https://artifacts.example.com/ah6vaaVaeng0xosh.raw.xz.sig 216 | sha256: ae3b0c44298fc1ce41e4649b149afbf4c8996fb92427934ca495991b7852b855 217 | uncompressed-sha256: 02e9df950c38acb1538d02d5ac0f2a278960d2799b4bdb59394e4eeabdd3a662 218 | 219 | images: 220 | # Cloud images to be launched directly by users. These are in a 221 | # separate section because they might not always in sync with the 222 | # release artifacts above. 223 | aliyun: 224 | regions: 225 | ap-northeast-1: 226 | release: 30.1.2.3 227 | image: m-cb2rfmhkcl2b6wedsbz5 228 | ap-south-1: 229 | release: 30.1.2.3 230 | image: m-ef3e19la2d35aftwxz5p 231 | aws: 232 | regions: 233 | us-east-1: 234 | release: 30.1.2.3 235 | image: ami-0123456789abcdef 236 | us-east-2: 237 | release: 30.1.2.3 238 | image: ami-0123456789abcdef 239 | azure: 240 | # We could give a specific image URN here, but we probably want 241 | # users to always use a Marketplace URN. So this is a static 242 | # string, and represents advice rather than a value we might 243 | # change. 244 | image: Fedora:CoreOS:stable:latest 245 | digitalocean: 246 | # We don't control platform ingest, so an image slug is probably 247 | # the best we can do. 248 | image: fedora-coreos-stable 249 | exoscale: 250 | image: Linux Fedora CoreOS 64-bit 251 | gcp: 252 | # Ideally users use the project + family. These are static strings, 253 | # and represent advice rather than a value we might change. 254 | project: fedora-coreos-cloud 255 | family: fedora-coreos-stable 256 | # As an alternative, we also list the currently recommended image 257 | # and its release. 258 | release: 30.1.2.3 259 | name: fedora-coreos-30-1-2-3-gcp-x86-64 260 | kubevirt: 261 | # ContainerDisk in a container registry 262 | # Ideally users use this pull spec, which specifies a floating tag. 263 | # This value is expected to be stable over time. 264 | image: exampleregistry.io/fcos/fcos:stable 265 | # As an alternative, we also list a digest-based pull spec for the 266 | # currently recommended image, and its release. 267 | release: 30.1.2.3 268 | digest-ref: exampleregistry.io/fcos/fcos@sha256:67a81539946ec0397196c145394553b8e0241acf27b14ae9de43bc56e167f773 269 | packet: 270 | # Images don't have addressable versions, so an operating system 271 | # slug is the best we can do. 272 | image: fedora_coreos_stable 273 | -------------------------------------------------------------------------------- /metadata/stream/sample.json: -------------------------------------------------------------------------------- 1 | { 2 | "stream": "stable", 3 | "metadata": { 4 | "last-modified": "2021-04-28T13:46:31Z", 5 | "generator": "fedora-coreos-stream-generator v0.1.0" 6 | }, 7 | "architectures": { 8 | "x86_64": { 9 | "artifacts": { 10 | "aliyun": { 11 | "release": "33.20210412.3.0", 12 | "formats": { 13 | "qcow2.xz": { 14 | "disk": { 15 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-aliyun.x86_64.qcow2.xz", 16 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-aliyun.x86_64.qcow2.xz.sig", 17 | "sha256": "35e80ce08915e58459537b46e75236f4eec7c2974933d9a32de6922fbce84eea", 18 | "uncompressed-sha256": "e23666a4e8c15bb80d2cbe2eff254037df0052d486c3841892c50025d40547a7" 19 | } 20 | } 21 | } 22 | }, 23 | "applehv": { 24 | "release": "33.20210412.3.0", 25 | "formats": { 26 | "raw.gz": { 27 | "disk": { 28 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-applehv.x86_64.raw.gz", 29 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-applehv.x86_64.raw.gz.sig", 30 | "sha256": "728e876d87ec71de27fc1d882840e6877346423433339a2b8606fa28e57413fd" 31 | } 32 | } 33 | } 34 | }, 35 | "aws": { 36 | "release": "33.20210412.3.0", 37 | "formats": { 38 | "vmdk.xz": { 39 | "disk": { 40 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-aws.x86_64.vmdk.xz", 41 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-aws.x86_64.vmdk.xz.sig", 42 | "sha256": "2dc2bd028edd52213c9a3a2ecc818307c2c5a0a13165747cbfeead4b8391e25b", 43 | "uncompressed-sha256": "cc7f0061511bb9949e81aa4d8678ad8eed2b0a3ced956fa64b851502be7dfbbd" 44 | } 45 | } 46 | } 47 | }, 48 | "azure": { 49 | "release": "33.20210412.3.0", 50 | "formats": { 51 | "vhd.xz": { 52 | "disk": { 53 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-azure.x86_64.vhd.xz", 54 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-azure.x86_64.vhd.xz.sig", 55 | "sha256": "9eaa0504ba6c33bd5baf21335ada861b5e01e8628ba40bc04050a436b3626a05", 56 | "uncompressed-sha256": "2593ac3d4e152fbbde9d7a5b1f0f69746a807148e1dbf64aa4f657da170dcece" 57 | } 58 | } 59 | } 60 | }, 61 | "azurestack": { 62 | "release": "33.20210412.3.0", 63 | "formats": { 64 | "vhd.xz": { 65 | "disk": { 66 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-azurestack.x86_64.vhd.xz", 67 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-azurestack.x86_64.vhd.xz.sig", 68 | "sha256": "3bd5baf21335ada861b5e01e8628ba40bc04050a436b9eaa0504ba6c33626a05", 69 | "uncompressed-sha256": "de9d7a5b1f0f69746a807148e1dbf64aa2593ac3d4e152fbb4f657da170dcece" 70 | } 71 | } 72 | } 73 | }, 74 | "digitalocean": { 75 | "release": "33.20210412.3.0", 76 | "formats": { 77 | "qcow2.gz": { 78 | "disk": { 79 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-digitalocean.x86_64.qcow2.gz", 80 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-digitalocean.x86_64.qcow2.gz.sig", 81 | "sha256": "2b0c7a697005f00bd99edd2c3bae80f258287843de6dc4e5d79b6ec1b6afb863" 82 | } 83 | } 84 | } 85 | }, 86 | "exoscale": { 87 | "release": "33.20210412.3.0", 88 | "formats": { 89 | "qcow2.xz": { 90 | "disk": { 91 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-exoscale.x86_64.qcow2.xz", 92 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-exoscale.x86_64.qcow2.xz.sig", 93 | "sha256": "4acb935fb4ef51c971172f4c71c81ba5fdf659aaad25be6fee83b83a6387cc32", 94 | "uncompressed-sha256": "459ace6388d56fc90281de7ee97dd4cc4cfa61143a894d24d3cf0ccf235ff07e" 95 | } 96 | } 97 | } 98 | }, 99 | "gcp": { 100 | "release": "33.20210412.3.0", 101 | "formats": { 102 | "tar.gz": { 103 | "disk": { 104 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-gcp.x86_64.tar.gz", 105 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-gcp.x86_64.tar.gz.sig", 106 | "sha256": "76fcc10bbba4517678217a81f95095702e83dc8ed3a2bc2d10062de214b55396" 107 | } 108 | } 109 | } 110 | }, 111 | "hetzner": { 112 | "release": "33.20210412.3.0", 113 | "formats": { 114 | "raw.xz": { 115 | "disk": { 116 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-hetzner.x86_64.raw.xz", 117 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-hetzner.x86_64.raw.xz.sig", 118 | "sha256": "728e876d87ec71de27fc1d882840e6877346423433339a2b8606fa28e57413fd" 119 | } 120 | } 121 | } 122 | }, 123 | "hyperv": { 124 | "release": "33.20210412.3.0", 125 | "formats": { 126 | "vhdx.zip": { 127 | "disk": { 128 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-hyperv.x86_64.vhdx.zip", 129 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-hyperv.x86_64.vhdx.zip.sig", 130 | "sha256": "728e876d87ec71de27fc1d882840e6877346423433339a2b8606fa28e57413fd" 131 | } 132 | } 133 | } 134 | }, 135 | "ibmcloud": { 136 | "release": "33.20210412.3.0", 137 | "formats": { 138 | "qcow2.xz": { 139 | "disk": { 140 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-ibmcloud.x86_64.qcow2.xz", 141 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-ibmcloud.x86_64.qcow2.xz.sig", 142 | "sha256": "aa1db0898fb88aae956343b99ca70975bd821050f274a79f63d18a2e2a489e26", 143 | "uncompressed-sha256": "cd7d5b979e15336e4c9b44f25cf86927fe4780b5775c2d02fe4f71827d820d4c" 144 | } 145 | } 146 | } 147 | }, 148 | "kubevirt": { 149 | "release": "33.20210412.3.0", 150 | "formats": { 151 | "ociarchive": { 152 | "disk": { 153 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-kubevirt.x86_64.ociarchive", 154 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-kubevirt.x86_64.ociarchive.sig", 155 | "sha256": "6343b99ca70975bd821050f274aa1db0898fb88aae95a79f63d18a2e2a489e26" 156 | } 157 | } 158 | } 159 | }, 160 | "metal": { 161 | "release": "33.20210412.3.0", 162 | "formats": { 163 | "4k.raw.xz": { 164 | "disk": { 165 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-metal4k.x86_64.raw.xz", 166 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-metal4k.x86_64.raw.xz.sig", 167 | "sha256": "c99e07bbdcb72615830985ddd1d63ab21779b874248952f15fd937ade5593c1c", 168 | "uncompressed-sha256": "8d6508b36095b78c6d306b0857a4a6272f5c25515a5c2f591f434290d63d88e1" 169 | } 170 | }, 171 | "iso": { 172 | "disk": { 173 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-live.x86_64.iso", 174 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-live.x86_64.iso.sig", 175 | "sha256": "97b7aed0086509c2187a4a9f91199aba7c430a5f9aface4e7b06cbcc664a0b4d" 176 | } 177 | }, 178 | "pxe": { 179 | "kernel": { 180 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-live-kernel-x86_64", 181 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-live-kernel-x86_64.sig", 182 | "sha256": "28314d6a50610dd342684d6edd19f386b8b8ee150f924775d81408be1987c3d8" 183 | }, 184 | "initramfs": { 185 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-live-initramfs.x86_64.img", 186 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-live-initramfs.x86_64.img.sig", 187 | "sha256": "5c7c0cc0a8c5d7a1894599ea1d1f5311a1cba0c8530decf9481d7e6cfc1873b7" 188 | }, 189 | "rootfs": { 190 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-live-rootfs.x86_64.img", 191 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-live-rootfs.x86_64.img.sig", 192 | "sha256": "50e63eddc657b24b86d53fbc267441d5e7e7c43eaac58ad9998dadd6141dc0b6" 193 | } 194 | }, 195 | "raw.xz": { 196 | "disk": { 197 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-metal.x86_64.raw.xz", 198 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-metal.x86_64.raw.xz.sig", 199 | "sha256": "6d18380dad77b8670767bb082bb6f55ae4381b2b1d4a7405d8a9cdb6e6678263", 200 | "uncompressed-sha256": "c8335d11257d33f7c68ce9720fd35ce0dfd008695348b58c7882d504eed974ed" 201 | } 202 | } 203 | } 204 | }, 205 | "nutanix": { 206 | "release": "33.20210412.3.0", 207 | "formats": { 208 | "qcow2": { 209 | "disk": { 210 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-nutanix.x86_64.qcow2", 211 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-nutanix.x86_64.qcow2.sig", 212 | "sha256": "650bb496c94c3fc815126daaa6beb2270ae870cb036df5b43c348da00e788dab" 213 | } 214 | } 215 | } 216 | }, 217 | "openstack": { 218 | "release": "33.20210412.3.0", 219 | "formats": { 220 | "qcow2.xz": { 221 | "disk": { 222 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-openstack.x86_64.qcow2.xz", 223 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-openstack.x86_64.qcow2.xz.sig", 224 | "sha256": "2270ae870cb036d650bb496c94c3fc815126daaa6bebf5b43c348da00e788dab", 225 | "uncompressed-sha256": "5c7e9e072ed6adc4f70ee78deaf5bde76426afcc35f620dad31d8b3eb697e16d" 226 | } 227 | } 228 | } 229 | }, 230 | "qemu": { 231 | "release": "33.20210412.3.0", 232 | "formats": { 233 | "qcow2.xz": { 234 | "disk": { 235 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-qemu.x86_64.qcow2.xz", 236 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-qemu.x86_64.qcow2.xz.sig", 237 | "sha256": "8dce159f743c777fe9c429648e8a16928b55d0c1bc8e599a82ba71870fdc5e5a", 238 | "uncompressed-sha256": "a21be448bb0ceee7a373cae232c4cadd979c3db844521d3c10888e42c405c684" 239 | } 240 | } 241 | } 242 | }, 243 | "qemu-secex": { 244 | "release": "33.20210412.3.0", 245 | "formats": { 246 | "qcow2.xz": { 247 | "disk": { 248 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-qemu-secex.x86_64.qcow2.xz", 249 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-qemu-secex.x86_64.qcow2.xz.sig", 250 | "sha256": "2afbb0ac4a19f58a55db35db0a690d488f065664e9bcba1b802966f0ae6aad57", 251 | "uncompressed-sha256": "2b1cb667f3468ef7b462e5ec8395fcd2982e424d1727336e95f74c611d8bbd53" 252 | } 253 | } 254 | } 255 | }, 256 | "virtualbox": { 257 | "release": "33.20210412.3.0", 258 | "formats": { 259 | "ova": { 260 | "disk": { 261 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-virtualbox.x86_64.ova", 262 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-virtualbox.x86_64.ova.sig", 263 | "sha256": "a54f52901817165c74b9d265d8ccf0a6c622006e2a13444fc1145970b8c9135d" 264 | } 265 | } 266 | } 267 | }, 268 | "vmware": { 269 | "release": "33.20210412.3.0", 270 | "formats": { 271 | "ova": { 272 | "disk": { 273 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-vmware.x86_64.ova", 274 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-vmware.x86_64.ova.sig", 275 | "sha256": "0a6c622006e2a13444fc1145970b8a54f52901817165c74b9d265d8ccfc9135d" 276 | } 277 | } 278 | } 279 | }, 280 | "vultr": { 281 | "release": "33.20210412.3.0", 282 | "formats": { 283 | "raw.xz": { 284 | "disk": { 285 | "location": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-vultr.x86_64.raw.xz", 286 | "signature": "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/33.20210412.3.0/x86_64/fedora-coreos-33.20210412.3.0-vultr.x86_64.raw.xz.sig", 287 | "sha256": "6c6a42c8399881e1ecb0ba088b389b4e20a394dacc3dab91f221fe18e5006557", 288 | "uncompressed-sha256": "835f97b63f18031f0eb830ee8766c6be8fec1e52f689156e761a92cd3573f4bb" 289 | } 290 | } 291 | } 292 | } 293 | }, 294 | "images": { 295 | "aws": { 296 | "regions": { 297 | "af-south-1": { 298 | "release": "33.20210412.3.0", 299 | "image": "ami-09d422b66ac91ab2a" 300 | }, 301 | "ap-east-1": { 302 | "release": "33.20210412.3.0", 303 | "image": "ami-05fdddb8ebfcdbbbd" 304 | }, 305 | "ap-northeast-1": { 306 | "release": "33.20210412.3.0", 307 | "image": "ami-0ecf122c9a4ec0c2f" 308 | }, 309 | "ap-northeast-2": { 310 | "release": "33.20210412.3.0", 311 | "image": "ami-08fd2b5b39b93b5ff" 312 | }, 313 | "ap-northeast-3": { 314 | "release": "33.20210412.3.0", 315 | "image": "ami-023a068f639e4d9dc" 316 | }, 317 | "ap-south-1": { 318 | "release": "33.20210412.3.0", 319 | "image": "ami-0bc108bb69dab2855" 320 | }, 321 | "ap-southeast-1": { 322 | "release": "33.20210412.3.0", 323 | "image": "ami-025fce39a4b9582a8" 324 | }, 325 | "ap-southeast-2": { 326 | "release": "33.20210412.3.0", 327 | "image": "ami-09186d20538071e92" 328 | }, 329 | "ca-central-1": { 330 | "release": "33.20210412.3.0", 331 | "image": "ami-0a186cd7e55176be2" 332 | }, 333 | "eu-central-1": { 334 | "release": "33.20210412.3.0", 335 | "image": "ami-06a0c31e4cba0c54d" 336 | }, 337 | "eu-north-1": { 338 | "release": "33.20210412.3.0", 339 | "image": "ami-01f6afff2c77bc11c" 340 | }, 341 | "eu-south-1": { 342 | "release": "33.20210412.3.0", 343 | "image": "ami-083a448ad9aff02c2" 344 | }, 345 | "eu-west-1": { 346 | "release": "33.20210412.3.0", 347 | "image": "ami-05b16c9ca91b37d57" 348 | }, 349 | "eu-west-2": { 350 | "release": "33.20210412.3.0", 351 | "image": "ami-0a5a690659a4e53bb" 352 | }, 353 | "eu-west-3": { 354 | "release": "33.20210412.3.0", 355 | "image": "ami-0ca82f640eae28513" 356 | }, 357 | "me-south-1": { 358 | "release": "33.20210412.3.0", 359 | "image": "ami-0f4a9bb1ea0c84082" 360 | }, 361 | "sa-east-1": { 362 | "release": "33.20210412.3.0", 363 | "image": "ami-0194168b04da77dfa" 364 | }, 365 | "us-east-1": { 366 | "release": "33.20210412.3.0", 367 | "image": "ami-09e2e5104f310ffb5" 368 | }, 369 | "us-east-2": { 370 | "release": "33.20210412.3.0", 371 | "image": "ami-02e593ebdf420390c" 372 | }, 373 | "us-west-1": { 374 | "release": "33.20210412.3.0", 375 | "image": "ami-0cb601c6edd617238" 376 | }, 377 | "us-west-2": { 378 | "release": "33.20210412.3.0", 379 | "image": "ami-0fcfe7120a4492fb9" 380 | } 381 | } 382 | }, 383 | "gcp": { 384 | "release": "33.20210412.3.0", 385 | "project": "fedora-coreos-cloud", 386 | "family": "fedora-coreos-stable", 387 | "name": "fedora-coreos-33-20210412-3-0-gcp-x86-64" 388 | } 389 | } 390 | } 391 | } 392 | } 393 | -------------------------------------------------------------------------------- /metadata/updates/fcos-updates-schema.json: -------------------------------------------------------------------------------- 1 | { 2 | "definitions": {}, 3 | "$schema": "http://json-schema.org/draft-07/schema#", 4 | "type": "object", 5 | "title": "updates", 6 | "description": "FCOS updates metadata JSON document.", 7 | "required": [ 8 | "releases", 9 | "metadata", 10 | "stream" 11 | ], 12 | "properties": { 13 | "releases": { 14 | "type": "array", 15 | "description": "Each entry MUST have a unique non-empty version field.", 16 | "items": { 17 | "type": "object", 18 | "description": "Release entry.", 19 | "required": [ 20 | "version", 21 | "metadata" 22 | ], 23 | "properties": { 24 | "version": { 25 | "type": "string", 26 | "title": "release version", 27 | "description": "Release version." 28 | }, 29 | "metadata": { 30 | "type": "object", 31 | "title": "release updates", 32 | "description": "Per-release updates metadata.", 33 | "properties": { 34 | "barrier": { 35 | "type": "object", 36 | "title": "barrier", 37 | "description": "Details on a release barrier.", 38 | "properties": { 39 | "reason": { 40 | "type": "string", 41 | "title": "barrier reason", 42 | "description": "URL to a document with the reason for this barrier." 43 | } 44 | }, 45 | "required": [ 46 | "reason" 47 | ] 48 | }, 49 | "deadend": { 50 | "type": "object", 51 | "title": "deadend", 52 | "description": "Details on a release dead-end.", 53 | "properties": { 54 | "reason": { 55 | "type": "string", 56 | "title": "deadend reason", 57 | "description": "URL to a document with the reason for this deadend." 58 | } 59 | }, 60 | "required": [ 61 | "reason" 62 | ] 63 | }, 64 | "rollout": { 65 | "type": "object", 66 | "title": "rollout", 67 | "description": "Details on a release rollout.", 68 | "properties": { 69 | "start_epoch": { 70 | "type": "integer", 71 | "title": "rollout start timestamp", 72 | "description": "UNIX epoch timestamp for the start of this rollout. Default: 0.", 73 | "default": 0 74 | }, 75 | "start_percentage": { 76 | "type": "number", 77 | "title": "rollout starting percentage", 78 | "description": "Starting point of this rollout, as decimal fraction ranging from 0.0 to 1.0. Default: 0.0.", 79 | "default": 0.0, 80 | "minimum": 0.0, 81 | "maximum": 1.0 82 | }, 83 | "duration_minutes": { 84 | "type": "integer", 85 | "title": "rollout duration", 86 | "description": "Duration in minutes for the rollout to progress till reaching 100% completion. Default: 0 (i.e. no progress).", 87 | "default": 0 88 | } 89 | } 90 | } 91 | } 92 | } 93 | } 94 | } 95 | }, 96 | "metadata": { 97 | "type": "object", 98 | "title": "document metadata", 99 | "description": "Metadata for this JSON document.", 100 | "required": [ 101 | "last-modified" 102 | ], 103 | "properties": { 104 | "last-modified": { 105 | "type": "string", 106 | "title": "last change timestamp", 107 | "description": "UTC timestamp for the last change, in ISO 8601 format." 108 | } 109 | } 110 | }, 111 | "stream": { 112 | "type": "string", 113 | "description": "Name of the release stream." 114 | } 115 | } 116 | } 117 | -------------------------------------------------------------------------------- /metadata/updates/sample.json: -------------------------------------------------------------------------------- 1 | { 2 | "stream": "testing", 3 | "metadata": { 4 | "last-modified": "2019-09-10T13:49:17+00:00" 5 | }, 6 | "releases": [ 7 | { 8 | "version": "30.20190716.1", 9 | "metadata": { 10 | "deadend": { 11 | "reason": "https://github.com/coreos/fedora-coreos-tracker/issues/215" 12 | } 13 | } 14 | }, 15 | { 16 | "version": "30.20190905.0", 17 | "metadata": { 18 | "rollout": { 19 | "start_epoch": 1568125800, 20 | "start_percentage": 0.3, 21 | "duration_minutes": 1440 22 | } 23 | } 24 | } 25 | ] 26 | } 27 | -------------------------------------------------------------------------------- /metadata/updates/specifications.md: -------------------------------------------------------------------------------- 1 | # Updates metadata specifications 2 | 3 | The updates metadata is a JSON document with a single object containing the following fields: 4 | 5 | - `stream` (mandatory, string): name of the update stream. 6 | - `metadata` (mandatory, object): metadata attributes for this JSON document. 7 | - `last-modified` (mandatory, string): UTC timestamp for the last change, in ISO 8601 format. 8 | - `releases` (mandatory, list of objects): per-release updates details. Each entry MUST have a unique non-empty `version` attribute. 9 | - `version` (mandatory, string): release version identifier. 10 | - `metadata` (mandatory, object): updates details. 11 | - `barrier` (optional, object): if present, the corresponding release is marked as an update barrier. 12 | - `reason` (mandatory, string): URL to a resource explaining the reason for this barrier. 13 | - `deadend` (optional, object): if present, the corresponding release is marked as an update dead-end. 14 | - `reason` (mandatory, string): URL to a resource explaining the reason for this dead-end. 15 | - `rollout` (optional, object): if present, the corresponding release is marked as an in-progress update rollout. 16 | - `start_epoch` (optional, signed integer): UNIX epoch timestamp for the start of this rollout. Default: `0`. 17 | - `start_percentage` (optional, float): starting point of this rollout, as decimal fraction ranging from `0.0` to `1.0`. Default: `0.0`. 18 | - `duration_minutes` (optional, unsigned integer): duration in minutes for the rollout to progress till reaching 100% completion. Default: `0` (i.e. no progress). 19 | 20 | # Glossary 21 | 22 | - **barrier**: a release which is a forced chokepoint for auto-updates. Releases older than a certain barrier must first update to it before proceding to more recent updates. 23 | - **dead-end**: a release which cannot further auto-update. Manual intervention is required to update out of it. 24 | - **rollout**: a release which can be used as a valid target for auto-updates. Multiple rollouts can exist and progress in parallel. 25 | -------------------------------------------------------------------------------- /metrics/README.md: -------------------------------------------------------------------------------- 1 | 2 | See [README.md](../README.md#metrics). 3 | -------------------------------------------------------------------------------- /stream-tooling.md: -------------------------------------------------------------------------------- 1 | # Stream tooling 2 | 3 | ## Introduction 4 | 5 | FCOS will have multiple streams: 6 | 7 | | Type | Name (SCM branch and ostree ref) | ostree repo | 8 | | -- | -- | -- | 9 | | Production | next | prod | 10 | | Production | testing | prod | 11 | | Production | stable | prod | 12 | | Development | testing-devel | annex | 13 | | Development | next-devel | annex | 14 | | Mechanical | rawhide | annex | 15 | | Mechanical | branched | annex | 16 | 17 | Development and mechanical streams are subject to change. 18 | 19 | We need a way to both (1) fix the content set for a particular stream release, and (2) integrate new content into development streams. 20 | 21 | ## Current tools at our disposal 22 | - git 23 | - rpm-ostree treefiles: manifest fed to rpm-ostree that contains the list of packages to use during a compose. [Example](https://github.com/coreos/fedora-coreos-config/blob/main/fedora-coreos-base.yaml). 24 | - rpm-ostree treefile locks: [pending rpm-ostree patch]( https://github.com/projectatomic/rpm-ostree/pull/1745) adding "lockfile" functionality similar to Cargo.lock/Gopkg.lock. This essentially means that the rpm-ostree compose is guaranteed to use specific package versions (or fail) as described in the lockfile. (To be clear, all of the below could probably be done without a lock file, since the treefile supports fully specifying the NEVRA, but having a separate lockfile allows for more sophisticated tooling and a cleaner treefile.) 25 | - Koji tags: a way to track packages built in Koji. Koji is capable of creating yum repos from such tags. RPM builds may be "tagged" in so that the next repo regeneration includes it. 26 | - [dist-git](http://src.fedoraproject.org/): git where RPM spec files are kept and Koji builds source from. 27 | 28 | ## Proposal 29 | 30 | **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`): 31 | 1. **rawhide** <- f32 32 | 2. **branched** <- f31 when a branch exists, otherwise tracks **rawhide** 33 | 34 | **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: 35 | 1. **next** <- coreos-pool 36 | 2. **testing** <- coreos-pool 37 | 3. **stable** <- coreos-pool 38 | 39 | **Development** streams are nightly snapshots of content headed for the production streams. There's one development stream at the base of each promotion path; thus, **stable** doesn't have one because it promotes from **testing** instead. **next-devel** will only be maintained in the periods where **next** is independent of **testing**. Development streams source their RPMs from a _single_ Koji tag, `coreos-pool`, from which we create a yum repo: 40 | 1. **next-devel** <- coreos-pool 41 | 2. **testing-devel** <- coreos-pool 42 | 43 | The Koji tag ensures that (1) packages are not automatically garbage collected, (2) stream builds are reproducible (up to the GC retention policy we agree upon), and (3) packages are added to the pool (and thus into the production streams) in a controlled manner. 44 | 45 | There is also a second Koji tag, `coreos-release`, for packages which have been included in a production build. Packages in `coreos-release` have a longer TTL than `coreos-pool`, increasing the time that official builds can be reproduced by others. 46 | 47 | ### How will the package list be maintained? 48 | 49 | 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. 50 | 51 | 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. 52 | 53 | 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. 54 | 55 | ### How will releases happen? 56 | 57 | When it's time to cut e.g. a promoted testing release, we push a merge commit to the testing branch which takes the testing-devel branch's tree in entirety. (That is, we use the Git "theirs" merge strategy, which, helpfully, doesn't exist.) We then tag the Git commit on the testing branch and do an official build and CI run. In the absence of flakes (ha!) this will pass because the commit is known to be green. If the build is bad, we abandon the release and iterate. Otherwise, we proceed with releasing artifacts. 58 | 59 | If we need to update an existing testing release, there's no need for another merge commit; we just commit changes to the testing branch and tag the release from there. 60 | 61 | ### How do packages get added to the koji tags? 62 | 63 | When a lockfile update is merged, this triggers a process which watches for pushes to the curated branches, and adds all the builds from the updated lockfile to `coreos-pool`. 64 | 65 | During production builds, the pipeline tags packages from the lockfile into `coreos-release`. 66 | 67 | ### Adding/removing packages to the OS 68 | 69 | Update the development treefile as usual. On the next bot push, the lockfile will be updated to include that package entry. 70 | 71 | 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): 72 | 73 | - **testing-devel** 74 | - **next-devel** -> automatically mirrored to branched 75 | - **rawhide** 76 | 77 | ### Dealing with backports 78 | 79 | There are two cases: 80 | 1. Backporting an already built Fedora package into a prod release: 81 | - We bump the override file entry for that specific package 82 | - The package automatically gets koji-tagged on push 83 | 2. Backporting a patch which isn't in a Fedora package (or the package was already updated too far): 84 | - We build the RPM from a dist-git branch 85 | - We add the RPM to the koji tag (though the build target destination tag could already be set to remove this manual tagging step) 86 | - We bump the override file entry for that specific package 87 | --------------------------------------------------------------------------------