k8s-style metadata on resources

[aegershman]

I find myself wanting to add metadata to controls with labels like "myorg.io/team: platform-engineering", "myteam.io/tier: networking", "myteam.io/contacts: [email protected],'beep bop'", `myteam.io/last-reviewed: '-or-github-issue'-- information which could be comments or shoved into the "implementation-statuses" field, but also feels like there's a place for them as structured data.

It might be worth considering having a field for "metadata" e.g. "metadata.labels" akin to k8s resource definitions. That way adhoc metadata can be added on a user-need basis for multiple purposes without having to worry about modifying the schema itself with top-level keys.

Another potential(?) use of this could be for integrating with output generators depending on the needs of the rendering target; for example, having metadata.annotations[open-control.io/frontmatter-keywords]: 'comma separated', 'list-of', 'keywords' could be used by output renderers (see opencontrol/compliance-masonry#346) to include (again, just for example) frontmatter keywords in the generated output of a markdown document for a control/entire component/etc., or control whether frontmatter is included in the output at all, etc.;

So if there were hugo-specific rendering directives, it would just be a metadata annotation. If there were jekyl-specific rendering directives, it would just be a metadata annotation, etc.

(this should be a separate issue, I apologize, but-- In the general case I feel the kubernetes schema is pretty dang powerful, and there are bits and pieces of ideas that could be pulled from it. It wouldn't be that out of the realm of possibility to me that, even though this isn't a k8s resource itself, the structure could be used; e.g., "metadata.name", apiVersion (schema_version), kind (control, component, policy, etc.); the details aren't fully thought through, but it's worth considering the generalized mapping)

Just wanted to put it down for consideration. thanks for the time 👍

[aegershman]

hm. I'm increasingly convinced it'd be a reasonable idea to adopt the k8s resource configuration model, where documents have the metadata.kind/metadata.apiVersion as part of standard metadata, and the actual content in the spec.<things> section.

There could be valuable even if it isn't an actual k8s resource. Then it'd be a known property that'd be on the resource which could be used by tools (masonry) to determine any version-specific details-- inspiration behind this is opencontrol/compliance-masonry#263 (comment)

just commenting to put the idea out there