#7202 Add a machine readable product id to the installation media buildstamp
Closed: Fixed 5 years ago Opened 6 years ago by m4rtink.

The current situation

At the moment the installation media buildstamp file has a field called "Product", which contains a human readable name of the product being installed.

The product name is used visually in multiple places in Anaconda (welcome screen, bootloader entries, etc.), but quite alarmingly, also as a kind of machine readable product identifier (base repo name, install class selection, etc.).

We have hit this issue yet again recently during an effort to merge back install classes for individual Fedora variants (Workstation, Server, etc.) to make install class maintenance easier & to make it possible to decommission the currently used per-variant product image packages.

Unfortunately we found out the "Product" field of every Fedora compose (rawhide/branched/GA) is, unlike on RHEL, always set to "Fedora", even if the compose & installation image itself is branded as Workstation/Server/etc. Also no other filed in the buildstamp has any information about about the variant at all.

Machine readable product id

Rather than requesting the variant name to be appended to the Product field and possibly breaking all software that assumes it will always be just "Fedora" and nothing else, we would like to suggest a different solution, possibly fixing this issue once and for all.

Rather than misusing the old human readable field, let's add a new field designed to hold a separate machine readable product id. That way Anaconda and other tools will not have to parse a human readable filed to detect a variant, making things much more robust. Also adding and properly specifying a new field should be generally much safer than changing the content of an existing one.

Specifying the product id field name & value

Looking at the current syntax, it looks like the field names are following a camel case convention (there is a BugURL and IsFinal field), so lets call the new field ProductId.

As for the machine readable product id value, I would suggest a few rules:

  • no whitespace
  • lower case ASCII letters, numbers and - only

I suggest this because it's quite likely the machine readable product id might end up on the filesystem as a folder or file name, so the string should be safe for this use-case.

Example .buildstamp file with ProductId:

[Main]
Product=Fedora
ProductId=fedora-workstation
Version=Rawhide
IsFinal=False
UUID=201711300745.x86_64
[Compose]
Lorax=28.2-1

I think it may be better to tie this more closely to pungi / productmd-defined concepts like 'variant', 'subvariant', 'shortname', etc. This proposal seems fairly nebulous as to what, exactly, ProductId represents - it should at least define this more clearly.

Some cases to think about: does a Fedora Modular Server image have the same ProductId as a Fedora Server non-modular image? Does a Fedora Workstation ostree image have the same ProductId as a Fedora Workstation non-ostree image?

Also, a pet peeve of mine, if you're going to allow - and _ in a string field such that they may be used to concatenate things, it's really nice to people trying to parse that field if you specifically define what they should be used for (and somehow ensure they're not used interchangeably or ambiguously).

Note that productmd already includes a lot of framework code for specifying constraints on the contents of various values.

I think it may be better to tie this more closely to pungi / productmd-defined concepts like 'variant', 'subvariant', 'shortname', etc. This proposal seems fairly nebulous as to what, exactly, ProductId represents - it should at least define this more clearly.

That could also be the way and it looks more clear to me what should be filled where.

To clarify the current proposal:

There should be unique product-id for every variant (e.g. fedora-server, fedora-modular-server, fedora-atomic...). Basically we need to be able to distinct between the variants and that black magic we are using now starts to be insufficient.

I would also like to see the list of used product-ids somewhere but I don't know the correct place for that yet.

I think it may be better to tie this more closely to pungi / productmd-defined concepts like 'variant', 'subvariant', 'shortname', etc.

That is a great idea. Actually, we only need to know the product (Fedora) and the variant (Server, Workstation). So instead of the ProductId field, we could add the Variant field that is already specified in productmd.

Also, a pet peeve of mine, if you're going to allow - and _ in a string field such that they may be used to concatenate things, it's really nice to people trying to parse that field if you specifically define what they should be used for (and somehow ensure they're not used interchangeably or ambiguously).

I agree. The text was already updated and it doesn't mention _ anymore.

I have no problem with extending the compose metadat, and the .buildstamp .treeinfo .composeinfo files etc. the work should all be done in lorax, pungi and productmd. with the tools all agreeing on what to do. @lsedlar and @bcl would be the ones to agree on how to implement it.

So, we kinda need this by F28 Beta release, because without it, Server images can't actually use the Server install class that's now been merged into anaconda, so they don't work right: they don't identify as "Fedora Server" during install, they don't use the right default filesystem, etc.

Either that, or we'd have to revert the merging of the install class into anaconda, I guess.

The Beta "target date" on the F28 schedule ATM is 2018-03-27, so I'm gonna say we'd want this done by two weeks before that, 2018-03-13. Do people think we're in a position to achieve that, or do I need to start coming up with contingency plans? Thanks.

@adamwill given that neither @lsedlar or @bcl have responded at all, I have no idea what answer to give you.

We have been thinking about how this could be done:

A "--product-variant" option could be added to Lorax, which adds a "Variant" field to the buildstamp, containing it's argument. So for example, you call lorax with:

--product="Fedora" --product-variant="server"

And the buildstamp on the image would contain:

Product: Fedora
Variant: server

The releng tooling that calls lorax would be changed to use the --product-variant option when running Lorax, providing the name of the variant it's trying to build.

Doesn't looks that complicated from the ammount of changes point of view to me, but I might be forgetting something. In any case feedback welcome! :)

Lorax already has a --variant argument, the content is written to the varient field of .treeinfo, adding it to .buildstamp shouldn't be a problem. If you do go this route please open a bug for it, I don't regularly follow threads here and (obviously) sometimes miss updates. Too many places to talk.

Pungi does not really do anything with the buildstamp file. Ideally Lorax should put the data there. Pungi already uses the --variant option, so if that value is used, nothing else would need to change.

We have an Anaconda PR ready, that can be merged once the Lorax part is done:
https://github.com/rhinstaller/anaconda/pull/1299

The .buildstamp parsing is based on what we expect Lorax to put there, but it can be easily adjusted if the actual output is different.

The Anaconda part has been merged and released in:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1018437

Looks like the Lorax part has been merged as well and released in:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1018170

So all should be now in place and install classes should be correctly selected once the new Lorax creates a compose with the new Anaconda.

Metadata Update from @syeghiay:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata