You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the v1.5 proposal process for formulation schema (or Manufacturing BOM, MBOM), the emphasis was on creating the new schema needed; however, the WG was presented additional considerations to better support formulation component types. Specifically, this list was presented as an initial concept list of new type values (cut/pasted) here:
Note: “component” should support new “type” enum. values.
Proposed minimum adds:
"configuration",
// includes K8s resource definitions (and downstream definitions from Knative, Tekton, etc.)
"tool",
// A hardware or software tool that was used in a task
// Note: Supports early examples where “tools” were special task objects
"task", // to designate workflow task “components” type
// Note: Could use “container” type for Tekton
"repository” (external, resource storage)
// define source/target for input/output to tasks e.g., GitHub
Others (TBD):
“storage” (more generic storage term)
“workspace” (in-workflow, ephemeral storage)
Describe the feature
Please note that many "components" of an MBOM may be ephemeral or logical in nature, but are backed by or represent physical entities (i.e., hardware, such as storage) or instances of data (such as configurations) that are created/instantiated during the formulation process perhaps by the underlying platform or execution environment.
This issue is intended to propose a set of new type values for discussion that will allow better clarity when creating and analyzing an MBOM what types of components were being used/where and for what purpose.
Possible solutions
Need to discuss with WG/core maintainers.
Alternatives
The proposal is specific to component types which is designed to be accommodating of such new types as new types of BOMs are formalized/published.
Additional context
None
The text was updated successfully, but these errors were encountered:
Please note that this exercise SHOULD also include MLBOM component types (for example for building ML models) such as tensor data, tokenizers, chat/prompt templates, etc.
mrutkows
changed the title
[FEATURE]: Add additional component types for Manufacturing/Formulation artifacts
[FEATURE]: Add additional component types for Manufacturing/Formulation/ML artifacts
Jan 8, 2025
Additional notes... "tools" are a key concept and are purposeful and ephemeral as they are being brought into specific tasks to perform a function for that task and then are typically not available in other tasks (i.e., removed). This is similar to the concept of a "configuration" file or dataset. Do we need to differentiate ephemeral components in some way?
These component-types are basically formulation specific, right?
They should not be used in other aspects of software-transparency (like SBOM).
If so, I would implement the JSON/XML/... in a way, that the $.formulation.components[] extends the global-defined component and add the additional options for compoennt-types enum.
During the v1.5 proposal process for formulation schema (or Manufacturing BOM, MBOM), the emphasis was on creating the new schema needed; however, the WG was presented additional considerations to better support formulation component types. Specifically, this list was presented as an initial concept list of new type values (cut/pasted) here:
Describe the feature
Please note that many "components" of an MBOM may be ephemeral or logical in nature, but are backed by or represent physical entities (i.e., hardware, such as storage) or instances of data (such as configurations) that are created/instantiated during the formulation process perhaps by the underlying platform or execution environment.
This issue is intended to propose a set of new type values for discussion that will allow better clarity when creating and analyzing an MBOM what types of components were being used/where and for what purpose.
Possible solutions
Need to discuss with WG/core maintainers.
Alternatives
The proposal is specific to component types which is designed to be accommodating of such new types as new types of BOMs are formalized/published.
Additional context
None
The text was updated successfully, but these errors were encountered: