Conventions on repo structure and artefact naming

[fzdarsky]

It would be useful to define and implement a convention on the structure of this repo and how produced artefacts (images, fleets, etc.) are named. This would make it easier

• for users to find demos interesting and relevant to them,
• for contributors to understand expectations and how to increase the chance of acceptance,
• for us when implementing a simple and generic CI/CD pipeline, and
• for Flight Control demo service users to look up what a demo fleet deploys.

Below is a proposal to illustrate and start the discussion.

Repo structure and naming:

/
├── images  # images that just contain the base OS + FC agent, used for testing and as base for demo images
│   ├── bootc 
│   │   ├── centos-bootc  # directory name == name of base distro image
│   │   ├── fedora-bootc
│   │   ├── rhel-bootc
│   │   └── ...
│   └── rpm-ostree
│       ├── rhel8
│       └── ...
├── demos
│   ├── demo1  # directory name == name of Container image == name of fleet when deployed
│   │   ├── bootc  # optional: contains everything that'll get built into thedirectory name == name of base distro image
│   │   │   ├── configuration  # build-time configuration (built into the image)
│   │   │   │   ├── etc  # structure config like it should appear on the target filesystem to make it easier to read
│   │   │   │   └── ...
│   │   │   ├── Containerfile
│   │   │   └── Containerfile.rhel9  # optional: if distro or arch or ... needs special-casing
│   │   ├── configuration  # optional: run-time configuration (to be applied by Flight Control)
│   │   │   ├── factoryA  # optional: substructure for device- or group-specific configurations
│   │   │   │   ├── etc  # structure config like it should appear on the target filesystem to make it easier to read
│   │   │   │   └── ...
│   │   │   └── factoryB
│   │   └── deployment  # fleet resource manifests to be applied to Flight Control
│   │           └── fleet.yaml
│   ├── demo2
│   │   └── ...
...

Demo naming:

• plain-{rhel9,fedora,...}: demos of fleets with just the base OS distro
• hello-{rpm,podman,microshift,kvm}: demos of a minimal "hello, world!" workload on different runtimes
• howto-*: demos to showing how to implement a certain technology, e.g. observability, security hardening, etc.
• usecase-*: demos of use cases like AI, robotics, etc.

Artefact naming:

• If possible, use the demo name (e.g. "hello-microshift") also as name of the deployment artefacts (e.g. "quay.io/flightctl-demos/hello-microshift:latest") and fleets.
• For the base agent images, use the same name+tag as the base distro. The agent is implied by the repo, e.g.. "quay.io/flightctl-demos/centos-bootc:stream9")

[astoycos]

I think we can also include some conventions on how we store the github actions workflows if that's the automation platform we'll be sticking with, that could also include naming conventions for shared workflows, I'll think on a structure and post back here.