Vision for configuration/builds about coreos-assembler HOT 7 CLOSED

This means that e.g. the equivalent of https://pagure.io/fedora-atomic should get "baked" into this container. (It doesn't mean that the config needs to live in this repo itself - but we should bake it in)

Should we bake it in or make it easily fetchable as a default location to pull from?

I'm thinking it should just be easily fetchable and if we run a command and it's not local then automatically fetch it.

from coreos-assembler.

I was thinking more about the UX of this container. Something like:

Getting Started

Provision a VM with nested virt in GCE, or a bare metal machine. We recommend Container Linux or Atomic Host, but anything that can run a container is fine (Ubuntu with docker/podman e.g.).

Creating a customization file

$ git clone https://github.com/coreos/coreos-assembler-example

Then edit it with:

# coreos-assembler customization file
from: fedora-28
name: exampleos
packages:
 - cowsay
updates:
 - https://exampleos.com/updates
postprocess: > 
  cat > /usr/lib/systemd/system/exampleos-hello-world.service << EOF
  [Service]
  Type=oneshot
  ExecStart=/usr/bin/echo Hello World
  EOF
  ln -s ../exampleos-hello-world.mount /usr/lib/systemd/system/local-fs.target.wants

Running

For this example we'll use podman, but you can also use docker.

$ podman pull quay.io/coreos/coreos-assembler

If you're running on a remote system, git clone your fork of the config, into e.g. /srv/exampleos/exampleos-config.

Choose an output directory; for this we'll use /srv/exampleos/output. If you're on a SELinux-enabled system (Fedora-derived systems), run chcon -t container_file_t:s0 /srv/exampleos/output.

Then:

$ podman run --security-opt seccomp=unconfined --rm -ti -v /srv/exampleos/config:/srv/config:ro -v /srv/exampleos/output:/srv/output quay.io/coreos/coreos/assembler

If we detect a curses UI, this will display a curses-based status, and also allow you to log in and debug things (e.g. virsh -c qemu:///session).

The /srv/exampleos/output directory will contain:

rojig/  # An rpm-md repo that one can place at the updates URL
images/20180804.0/exampleos-20180804.0.qcow2.gz 
                                exampleos-20180804.iso

And then it should be possible to iterate quickly - edit the config file, rerun, and have a new rojig + image.

We should include https://github.com/cgwalters/playground/blob/master/coreos-run-qemu to make it trivial to log into a built image and play with it. In this scenario, after loggin into the built image, notice that cowsay is installed, and that exampleos-hello-world.service works.

After this

We should also have an opinionated default path for building components from sources. Also, make it easy to pre-bake in container images, not just RPMs.

from coreos-assembler.

we could even recommend an alias to make it easier: alias coreos-assembler=podman run --rm -ti -v /srv/exampleos/config:/srv/config quay.io/coreos/coreos/assembler

And rather than git clone https://github.com/coreos/coreos-assembler-example what about coreos-assembler new config

from coreos-assembler.

OK, I created https://github.com/cgwalters/fedora-coreos-config

from coreos-assembler.

WIP in #29

from coreos-assembler.

One thing I'm uncertain about right now is whether this repo has a config file or other logic (e.g. Makefile) defining what targets get built.

It's likely we should always build a qemu image, but do we want to generate all possible images (aws, etc.) by default?

I'm leaning a bit towards build actually invoking an internal Makefile with targets like all, tree, image-qemu, image-aws etc.

And then do we wrap e.g. ore as coreos-assembler aws-upload?

from coreos-assembler.

We did most of this.

from coreos-assembler.