[releng] Issue #7202: Add a machine readable product id to the installation media buildstamp
m4rtink reported a new issue against the project: `releng` that you are following: `` 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 _ 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 ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
adamwill added a new comment to an issue you are following: `` 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). ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
adamwill added a new comment to an issue you are following: `` Note that productmd already includes a lot of framework code for specifying constraints on the contents of various values. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
jkonecny added a new comment to an issue you are following: ``
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-id`s somewhere but I don't know the correct place for that yet. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
vponcova added a new comment to an issue you are following: ``
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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
ausil added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
adamwill added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
ausil added a new comment to an issue you are following: `` @adamwill given that neither @lsedlar or @bcl have responded at all, I have no idea what answer to give you. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
m4rtink added a new comment to an issue you are following: `` 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 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! :)
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
bcl added a new comment to an issue you are following: `` 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.
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
lsedlar added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
m4rtink added a new comment to an issue you are following: `` @bcl: RFE bug created for the Lorax functionality: https://bugzilla.redhat.com/show_bug.cgi?id=1532695 ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
m4rtink added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
m4rtink added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7202
The status of the issue: `Add a machine readable product id to the installation media buildstamp` of project: `releng` has been updated to: Closed as Fixed by syeghiay.
rel-eng@lists.fedoraproject.org
-
Adam Williamson -
Brian C. Lane
-
Dennis Gilmore
-
Jiří Konečný
-
Lubomír Sedlář
-
Martin Kolman
-
Suzanne Yeghiayan
-
Vendula Poncova