Labeling supported architectures and runtime introspection

[lucab]

This is a public followup to an offline discussion started with @jlebon.

On FCOS, we maintain a table of well-known platforms, so that software running on a node can introspect this at runtime by looking up the OEM-ID from kernel command-line.

Similarly, we should maintain a table of well-known architectures. Currently we only have amd64, but more are coming (see #78).

Additionally, it should be possible for a node to introspect its own OS architecture. An example of such a usecase would be for the update client to communicate this to the update-serving backend.

It looks like there are two approaches currently in use:

• using the kernel arch label (uname -m)
• using the librpm/libdnf canonical base arch name. This is what rpm-ostree uses.

I don't know where Fedora proper maintains such a table, but it would be nice to be aligned on that. Assuming such table is based on the latter approach, we should provide some way to read that information without linking to libdnf. In Container Linux this information was part of the "board label" in os-release, but pretty much any file in a machine-friendly format under /usr would be fine.

[cgwalters]

Without linking anything:

# rpm --eval '%{_arch}'
x86_64

But no objections to sticking this somewhere as JSON in /usr either. We could easily emit it from rpm-ostree status --json as well.

[jlebon]

# rpm --eval '%{_arch}'

Isn't that arch though and not base arch? I think @lucab is looking for a way for a process to know "which FCOS basearch am I?" without having to maintain a table similar to libdnf's.

In Container Linux this information was part of the "board label" in os-release, but pretty much any file in a machine-friendly format under /usr would be fine.

I like the idea of putting it in os-release, e.g. COREOS_BASEARCH?

[dustymabe]

• using the kernel arch label (uname -m)

Assuming uname -m matches what Fedora is expected I'm cool with that.

• using the librpm/libdnf canonical base arch name. This is what rpm-ostree uses.

This would be the safer approach.

I'd personally prefer not to add a new place for people to find this information that is specific only to Fedora CoreOS and not applicable to Fedora.

[jlebon]

I opened a proposal at coreos/rpm-ostree#1766 to just include the base arch as part of the treefile. So one can simply read /usr/share/rpm-ostree/treefile.json.

[dustymabe]

is there a reason to do that vs using librpm/libdnf? i.e. is it easier for some software to read that file (json) than it is to call the library?

[cgwalters]

is there a reason to do that vs using librpm/libdnf?

libdnf is not a public stable API and I doubt it will be anytime soon.

i.e. is it easier for some software to read that file (json) than it is to call the library?

Reading a JSON file is significantly easier for e.g. Go code than calling into C.

That said...I am not sure why this API doesn't live in librpm. Maybe the naming of architectures differs even across RPM-using distributions?

[cgwalters]

We do ship librpmostree.so though which is API/ABI stable and also accessible via GObject Introspection even and can work even on "classic" systems.

[dustymabe]

mike-nguyen closed this in [mike-nguyen/rpm-ostree@2be532c](/mike-nguyen/rpm-ostree/commit/2be532c9e99db4f495ecc6807bca468f16260f34) 15 minutes ago

wow didn't know you could do that across repos

[mike-nguyen]

If I closed something it was unintentional!

[jlebon]

I did mean for coreos/rpm-ostree#1766 to close this, but for some reason it didn't when it got pushed to master, but it did when you pushed it to your fork. I'm guessing some permissions issue maybe?

[mike-nguyen]

If it is supposed to be closed then no big deal. I was just syncing my fork with upstream. Really weird though.

[cgwalters]

I'm guessing some permissions issue maybe?

Pretty sure it's because @rh-atomic-bot did the push and has access to rpm-ostree but not this repo.

[lucab]

There is followup from an out-of-band discussion at coreos/rpm-ostree#1766 (comment). We are thinking of augmenting mutate-os-release treefile feature to also inject a basearch field into os-release, and enabling that feature for FCOS.

[dustymabe]

There is followup from an out-of-band discussion at projectatomic/rpm-ostree#1766 (comment). We are thinking of augmenting mutate-os-release treefile feature to also inject a basearch field into os-release, and enabling that feature for FCOS.

How does the os-release file get generated to begin with? I'd prefer if we make the change for all of Fedora and not just for ostree based systems.

[lucab]

@dustymabe https://src.fedoraproject.org/rpms/fedora-release/blob/f30/f/fedora-release.spec#_378 however the package itself is noarch.

[dustymabe]

@dustymabe https://src.fedoraproject.org/rpms/fedora-release/blob/f30/f/fedora-release.spec#_378 however the package itself is noarch.

If the file is dynamically updated during rpm scriptlets then the package could still be noarch, but that would beg the question: If we can dynamically update it during rpm scriptlets then where are we pulling that information from and why couldn't consumers of this new interface do the same thing?

This gets us back to an earlier comment I had:

I'd personally prefer not to add a new place for people to find this information that is specific only to Fedora CoreOS and not applicable to Fedora.

[jlebon]

Looking to resolve this soon in order to address coreos/coreos-assembler#463 (comment). Interestingly, cosa will need that information as well, so it is indeed not just about runtime FCOS introspection.

I'd personally prefer not to add a new place for people to find this information that is specific only to Fedora CoreOS and not applicable to Fedora.

The issue is that what applies to traditional Fedora in this case literally can't be applied to FCOS. Here's a suggested answer on how to do this on traditional Fedora (https://unix.stackexchange.com/a/317487):

$ python3 -c '
import dnf, pprint
db = dnf.dnf.Base()
pprint.pprint(db.conf.substitutions,width=1)'

{'arch': 'x86_64',
 'basearch': 'x86_64',
 'releasever': '30'}

This works off of uname -m and then a lookup in a clone of that libdnf table: https://github.com/rpm-software-management/dnf/blob/10f1ad2386fde35fb20027782514debb4a0454f4/dnf/rpm/__init__.py#L88.

But of course we ship neither python3 nor dnf in FCOS. :)

My suggestion right now is that instead of maintaining another table (even though it'd be much smaller since we only care about a subset of these architectures) is to teach cosa to pick up the base arch from rpm-ostree:

$ python3 -c '
import gi
gi.require_version("RpmOstree", "1.0")
from gi.repository import RpmOstree
print(RpmOstree.get_basearch())'

x86_64

and inject that into the OSTree (e.g. either in the commit metadata, or a file, or maybe both). This means we use the exact same table as the rest of Fedora. We should also probably use that in cosa itself instead of uname -m to have arch-specific behaviours (like here -- this code right now will fail if uname -m returns amd64).

So to answer one of the original comment of this issue:

Similarly, we should maintain a table of well-known architectures.

This would live in cosa, which I think seems like a fitting place since a lot of the enablement for each arch happens there.

[jlebon]

teach cosa to pick up the base arch from rpm-ostree

I guess we could use the dnf code I pasted above to do this too, but cosa has a runtime dependency on rpm-ostree, and only a build dependency on dnf (e.g. we could technically delete dnf from the container after it's built).

Also, rpm-ostree uses the libdnf table, not the dnf copy (although the libdnf one was originally taken from dnf...), and I think the goal is to eventually dedupe these things into libdnf. And it's the same table rpm-ostree in FCOS would use for e.g. package layering.

[cgwalters]

If cosa needs the table we could have e.g. rpm-ostree compose --print-architecture-json or something that would dump it in JSON form.

[cgwalters]

(Of course doing that would probably require a libdnf patch to add API)

[jlebon]

Yeah, though hopefully cosa doesn't need the table itself, just the ability to lookup. So e.g. the table in cosa would be more of a list of supported base archs.

[jlebon]

Injected in commit metadata in coreos/coreos-assembler#590 (coreos/coreos-assembler@62ad7de). See commit message for some of the rationale, though open for discussions!

[jlebon]

Fixed by coreos/coreos-assembler#590.

[jlebon]

Example rpm-ostree status --json:

{
  "deployments" : [
    {
      "unlocked" : "none",
      "requested-local-packages" : [
      ],
      "base-commit-meta" : {
        "coreos-assembler.config-dirty" : "true",
        "coreos-assembler.config-gitrev" : "e5ffda727170e124c7f7d8782e256b0462bf9869",
        "coreos-assembler.basearch" : "x86_64",
        "rpmostree.inputhash" : "0e2ba98bac847c8a8cc5ffd42822a41d53ef6719ccaf6a0094559768aa24da33",
        "version" : "30.1",
        "rpmostree.rpmmd-repos" : [
          {
            "id" : "fedora-coreos-pool",
            "timestamp" : 7435743550895030272
          },
          {
            "id" : "fedora",
            "timestamp" : -7689964138319052800
          },
          {
            "id" : "fedora-updates",
            "timestamp" : -1292510703390818304
          },
          {
            "id" : "coreos-assembler-local-overrides",
            "timestamp" : 1402332922660257792
          }
        ]
      },
      "base-removals" : [
      ],
      "gpg-enabled" : false,
      "origin" : "fedora/x86_64/coreos/testing-devel",
      "osname" : "fedora-coreos",
      "pinned" : false,
      "requested-base-local-replacements" : [
      ],
      "checksum" : "ce718b90ce19c2cac07fa45efdce91aad208a508c98e9f7f572f5aaba76f569a",
      "regenerate-initramfs" : false,
      "id" : "fedora-coreos-ce718b90ce19c2cac07fa45efdce91aad208a508c98e9f7f572f5aaba76f569a.0",
      "version" : "30.1",
      "requested-packages" : [
      ],
      "requested-base-removals" : [
      ],
      "serial" : 0,
      "base-local-replacements" : [
      ],
      "timestamp" : 1561753297,
      "booted" : true,
      "packages" : [
      ]
    }
  ],
  "transaction" : null,
  "cached-update" : null
}

[keithy]

Since bash is not great at reading json, I think it is needed in /etc/os-release such that systemd unit can use
EnvironmentFile=/etc/os-release

OSTREE_VERSION is in there, and so to construct a url to a downloadbale executable, BASE_ARCH is the missing piece.

[dustymabe]

Since bash is not great at reading json

jq is in FCOS for parsing json from bash