Discussion on what ldmsd (and storage plugin) should do when a set schema definition has changed

[nichamon]

Background

The store_sos plugin was recently modified to prevent assertion failures when type mismatches occur between LDMS metrics and SOS attributes (Issue 1524). While this prevents crashes, it introduces a new issue where sets with mismatched types are not stored at all.

A proposed solution involves storing the Set digest (SHA Hash) in the SOS Schema in the database. However, this proposal needs further discussion on how to handle digest mismatches when they occur.

Current Behavior

• Assertion failures are prevented when type mismatches occur
• Sets with mismatched types are not stored

We Need Your Input

Schema Change Scenarios

Please describe scenarios you've encountered where schema definitions have changed in your LDMS deployments:

• What caused the schema change?
• What types of schema changes occur, e.g., adding new metrics, removing new metrics, changing metric type, others?

Data Usage Patterns

Please describe how you use the stored data:

• How do you query or analyze the historical data?
• Do you need to correlate data across different schema versions?
• What are your typical data access patterns?

Operational Requirements

• What behavior would be most helpful when a schema change is detected?
• How important is historical data access?
• What kind of visibility or notification would you need?