Multiple image files for a single image

[deitch]

This is a discussion issue to figure out how we handle multiple image yml files. As of this writing, and the recently merged #849, we have multiple rootfs image files:

1. A core rootfs.yml which contains all of the common information for images
2. A patch file per unique build, e.g. Xen or KVM or RPi

Actually, each is a .yml.in which then is merged and patched, but getting past .in files is a separate discussion.

The problem with using patch files in this use case is that they are brittle. They have very specific lines that you add/remove/change. This works well for source code, where lines have little inherent structure. yml (and json) are by definition structured and easy to patch. There even are RFC standards for json patch and json merge patch.

The kubernetes version of strategic merge patch is even easier, but is not an RFC, and depends on some annotations or other logic of how to handle lists.

A JSON Patch style, done as yml, to replace rootfs-acrn.yml.in would look something like:

- op: replace
  path: "/kernel/image"
  value: ACRN_KERNEL_TAG
- op: replace
  path: "/init/7"
  value: ACRN_TAG
- op: remove
  path: "/services/10"
- op: test
  path: "/init/7"
  value: XEN_TAG
- op: test
  path: "/services/10/image"
  value: XENTOOLS_TAG

A json merge patch wouldn't work, since a jsonmerge patch replaces an entire list.

Finally, we could look at the Kubernetes version of the strategic merge patch, which, if planned correctly, would let us do something like this:

kernel:
  image: ACRN_KERNEL_TAG   // change the /kernel/image value to ACRN_KERNEL_TAG
init:
  - ACRN_TAG    // add the primitive "ACRN_TAG" to the list "init"
services:
   - name: xen-tools
     $patch: delete  // delete the item whose name is "xen-tools"
$deleteFromPrimitiveList/init:
  - XEN_TAG   // delete "XEN_TAG" from the primitive list

This came from a discussion with @rvs

An alternate approach would be to get multiple files into linuxkit, just as we do with docker-compose. E.g.

linuxkit build rootfs.yml acrn.yml

We have discussed it in linuxkit, but never came to a conclusion. I would be willing to pursue it further.

[deitch]

FYI, I am not completely convinced that any of the above is better than "patch", except for having our tools having it built in. My issue with patch is that some places might not have it installed, and it is brittle as it is tightly dependent on line numbers and specific content. Any change to rootfs.yml will lead to work fixing all of the now-3-but-will-grow patch files.