rpm-ostree status --json does not properly serialize ostree.manifest for OCI deployments

[jbtrystram]

Describe the bug

When the booted deployment is a container image , the output of rpm-ostree status --json does not properly serialize a few keys under base-commit-meta :
ostree.manifest and ostree.container.image-config are both serialized as strings with the JSON structure escaped.

Reproduction steps

1. rebase to a container image: rpm-ostree rebase ostree-unverified-registry:quay.io/fedora/fedora-coreos@sha256:d12dd2fcb57ecfde0941be604f4dcd43ce0409b86e5ee4e362184c802b80fb84 then reboot
2. run rpm-ostree status --json
   3 . output :

{
  "deployments": [
    {
      "unlocked": "none",
      "requested-local-packages": [],
      "base-commit-meta": {
        "ostree.importer.version": "0.14.1",
        "ostree.tar-filtered": {},
        "ostree.manifest": "{\"schemaVersion\":2,\"config\":{\"mediaType\":\"applic........ [snip]",
        "ostree.container.image-config": "{\"created\":\"2024-11-25T02:09:37Z\", ........[snip]",
        "ostree.manifest-digest": "sha256:d12dd2fcb57ecfde0941be604f4dcd43ce0409b86e5ee4e362184c802b80fb84"
      },
      "base-removals": [],
      "pinned": false,
      "osname": "fedora-coreos",
      "base-remote-replacements": {},
      "regenerate-initramfs": false,
      "checksum": "41e8b64a8995e7412047dc0436934df69cb7886c73c2476f5743ba752dbb3e98",
      "container-image-reference-digest": "sha256:d12dd2fcb57ecfde0941be604f4dcd43ce0409b86e5ee4e362184c802b80fb84",
      "requested-base-local-replacements": [],
      "id": "fedora-coreos-41e8b64a8995e7412047dc0436934df69cb7886c73c2476f5743ba752dbb3e98.0",
      "version": "41.20241109.3.0",
      "requested-local-fileoverride-packages": [],
      "requested-base-removals": [],
      "requested-packages": [],
      "serial": 0,
      "timestamp": 1732500577,
      "staged": false,
      "booted": true,
      "container-image-reference": "ostree-unverified-registry:quay.io/fedora/fedora-coreos@sha256:d12dd2fcb57ecfde0941be604f4dcd43ce0409b86e5ee4e362184c802b80fb84",
      "packages": [],
      "base-local-replacements": []
    }
  ],
  "transaction": null,
  "cached-update": null,
  "update-driver": null
}

Expected behavior

I am expexting ostree.manifest and ostree.container.image-config to be properly serialized as JSON objects

Actual behavior

ostree.manifest and ostree.container.image-config are serialized as strings

System details

rpm-ostree:
 Version: '2024.9'
 Git: bd152998332c2b11af671447d3fd311319d5b3a8
 Features:
  - rust
  - compose
  - container
  - fedora-integration

Additional information

No response

[travier]

I think it's on purpose as de-serializing those would change the format of the JSON output of rpm-ostree status in an unpredictable way.

[cgwalters]

There's a different alternative here - first try parsing bootc status. That will already strongly differentiate the container vs ostree case.

[cgwalters]

Now that in turn actually relates to containers/bootc#348

[jbtrystram]

There's a different alternative here - first try parsing bootc status. That will already strongly differentiate the container vs ostree case.

Good suggestion, thanks. I just looked into it and that would not work for zincati because I need to find out the coreOS stream from the ostree manifest to query the update graph from cincinnati

[cgwalters]

The stream is already part of the standard label metadata:

$ podman inspect quay.io/fedora/fedora-coreos:testing-devel | jq .[0].Labels
{
  "containers.bootc": "1",
  "coreos-assembler.image-config-checksum": "7785d2c62ec40bdf6ca4f25477f4ca121f98482efb0846ee1980f74d4c741663",
  "coreos-assembler.image-input-checksum": "b3d4fc7480d1d9fefdc2423d5b76e7c397dfd9a273e568cf47a2a67e56e692ca",
  "fedora-coreos.stream": "testing-devel",
  "org.opencontainers.image.revision": "e97a55b18aa2478bd01c38ed725f8c528555c030",
  "org.opencontainers.image.source": "https://github.com/coreos/fedora-coreos-config",
  "org.opencontainers.image.version": "41.20241208.20.0",
  "ostree.bootable": "true",
  "ostree.commit": "87be140031780bbccb9cbe115170307179c6425bac9f7fb6253687e3ab7a0464",
  "ostree.final-diffid": "sha256:12787d84fa137cd5649a9005efe98ec9d05ea46245fdc50aecb7dd007f2035b1",
  "ostree.linux": "6.11.10-300.fc41.x86_64",
  "rpmostree.inputhash": "4a211f37c9e2de7db16520da88516a37d74de0a441ab3719cfc3ffa62183bdc4"
}

So if we exposed the manifest/config metadata from bootc (which is containers/bootc#348 ) then that's all that's needed, no?

[jbtrystram]

So if we exposed the manifest/config metadata from bootc (which is containers/bootc#348 ) then that's all that's needed, no?

Yes !

[cgwalters]

I think my proposal for now is zincati forks off and parses ostree container image metadata until we expose it via bootc

[jlebon]

Hmm, I think this is related to #5120. If Zincati uses that, then we can also get the stream information from the custom origin. Or with the idea of the custom origin URL being to the graph OCI artifact, then Zincati can directly use the graph located there; I think then Zincati wouldn't really need to understand streams at all.

[cgwalters]

Hmm, I think this is related to #5120.

That is a valid approach for sure, however that custom origin stuff isn't in bootc which won't understand it (which is probably both good and bad).

[jbtrystram]

Hmm, I think this is related to #5120. If Zincati uses that, then we can also get the stream information from the custom origin. Or with the idea of the custom origin URL being to the graph OCI artifact, then Zincati can directly use the graph located there; I think then Zincati wouldn't really need to understand streams at all.

I think this was part 2 of the two step plan, currently we don't publish the update graph as the OCI artifact, do we ?
If custom_origin can be any URL, then we could simply put the cincinnati URL with the correct parameters and use that in Zincati, in the meantime.

IMHO, parsing both rpm-ostree --json output correctly in zincati is the simplest solution until the full bootc switch : #5208