Skip to content

Design pipeline configuration strategy #618

Closed
@jlebon

Description

We're working on making this pipeline usable to build RHCOS too. At a high-level, the biggest difference between RHCOS and FCOS in that respect is that the RHCOS streams have very different lifecycles.

E.g. OCP 4.6 was released Oct 27, 2020. Maintenance will end Oct 27 2022. Many features and platforms were added since then, but we don't ship them for 4.6. Contrast with FCOS, where stable is at most 4 weeks apart from testing-devel. (This is also why branching cosa is much more needed for RHCOS than FCOS, where we're only recently getting around to doing this.)

As we add support for building RHCOS with this pipeline, we need to have some things be configurable. Here's a (likely non-comprehensive) list of possible configuration knobs:

  • whether to build all bootimages
  • whether to upload to AWS GovCloud or not (usually, dev streams are not until they GA)
  • whether to build artifacts for certain platforms (e.g. we shouldn't build Nutanix images for streams older than 4.10 where enablement was done)
  • sharing AMIs with specific OpenShift CI accounts
  • uploading to some AWS/Aliyun zones

The way the existing RHCOS pipeline does this is using a "jobspec", which is a YAML file full of knobs. Though it also includes pipeline details like secret names and pod resource requests.

Another big one is the actual list of streams. Currently, this pipeline hardcodes stable, testing, ... The existing RHCOS pipeline avoids this by branching the pipeline code itself per releases, which has its own set of tradeoffs.

Metadata

Assignees

No one assigned

    Labels

    jiraFor syncing to JIRA

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions