Docs: table/feature matrix generation

[sdktr]

As a followup of this comment: #3492 (comment)

We should discuss which parts of the docs contain duplicate information with other data structures. Using the code version of this info as SoT for the docs where possible avoids a duplicate of error prone administration.

List of duplicate information:

1. supported platforms/device types (source: yaml)
2. supported features per platform (source: yaml)
3. quirks per feature per platform (source: quirks code)

YAML: can be parsed as is(?)
Quirks: can be annotated with metadata to have all the info needed?

Where in the pipeline should we parse this into human readable docs format? Where it's already done today (mkdocs of some sort?)?

[sdktr]

4. test results per feature per platform? Eg: desired vs observed feature conformation?

[DanPartelly]

Do you offer to implement it, or do you just wanna discuss it ?

[sdktr]

If we get a good overview of the desired outcome I want to give the actual implementation a try 👍

i thought about this while AFK so this discussion is my initial brain dump on the matter. Feel free to add your insights/prios/desired way of working when documenting a feature.

[ipspace]

From where I sit:

• Generating support tables from device definitions (augmented with caveat pointers as needed) is doable. I'm working on it in the sphinx-features branch. Wasted a few hours trying to figure out how to generate "Junos includes these devices" footnotes. As expected, AI was of great help, politely and enthusiastically walking me in circles. Now that I know how to generate the footnotes, I'll try to deal with the complexities of parent devices. I might have something "in production" (for one or two simple modules) by the end of the week.
• Figuring out platform tables from device quirks is interesting (see https://xkcd.com/1425/). We could probably use AI to compare quirks to device caveats and point out inconsistencies or even fix them. If anyone is willing to donate tokens to the CI/CD pipeline, they're most appreciated ;)
• Tying caveats to integration test results is somewhat easier, but maybe not worth the effort.

[ipspace]

Interim code in https://github.com/ipspace/netlab/tree/sphinx-features -- once I implement caveats, I'll use it to replace BFD feature table.