support `cosa init --ostree docker://quay.io/coreos-assembler/fcos:testing-devel`

[cgwalters]

This is part of coreos/fedora-coreos-tracker#828 conceptually, which was actually in retrospect framed too broadly. Focus shifted to coreos layering but that's really the "user experience" half. Re engineering how we build and ship FCOS (the first issue) still applies.

In particular, I think we should support a cosa init --ostree mode that takes a container image as input and outputs just a container. We may not even generate a builds/ directory, and no meta.json stuff should be created for this.

flowchart TB
    quayprevious["previous ostree container"] --> ostreebuild
    subgraph ostreebuild [cosa ostree build]
    configgit["config git"]-->container
    rpms --> container["ostree container"]
    container --> quay["quay.io"]
    end
    subgraph imagebuild [cosa image build]
    quay --> qemu["qemu image"]
    quay --> metal
    metal --> iso
    qemu --> ami
    qemu --> vsphere
    qemu --> gcp
    end


    imagebuild --> S3

Loading

imagebuild -->

Note how the input to "cosa image build" is just the ostree container, not config git (or rpms).

Further, I want to emphasize that the "build ostree container" and "build disk images" can (and would normally be) separate processes. (Now, how testing is integrated here is not depicted, but basically we'd still probably generate a qemu image to sanity test our container builds, but it would be discarded and regenerated by the image build process only once that image had passed other approvals)

[cgwalters]

A specific thing this would really help unblock is reworking our build/CI flow to be more like:

• check for changes in input
• build new container image
• Do sanity checks on that container image as a container (perhaps systemd-in-container even)
• Push that container image to registry

The remainder of stuff here could be parallelized/configurable:

• Kick off upgrade tests from the previous stable release
• Generate a fresh qemu image and run qemu basic tests
• Do ISO/metal tests
• Do cloud tests

And we could now much more naturally represent stages of CI with container image tags. For example we might push fcos:testing-devel-candidate or so. And then only tag to fcos:testing-devel once some of those tests have passed.

[cheesesashimi]

For example we might push fcos:testing-devel-candidate or so. And then only tag to fcos:testing-devel once some of those tests have passed.

This is my favorite part of this. This would enable consumers of these images to get feedback about the overall image state.

Just to clarify, when you say OCI standard keys, are you referring to https://github.com/opencontainers/image-spec/blob/main/annotations.md?

[cgwalters]

Yep! Specifically org.opencontainers.image.source and org.opencontainers.image.revision.

[cgwalters]

ostreedev/ostree-rs-ext#234 will help this

[dustymabe]

I'm not sure I understand the value here. Maybe we can talk about it at the next video community meeting to make it more clear for people.

[cgwalters]

ostreedev/ostree-rs#47

[dustymabe]

ostreedev/ostree-rs#47

Was that a response to me? If so I still don't understand how that answers the question.