Hi SeungMin, Thank you for the detailed proposal. I've been thinking about the target audience and wanted to share some thoughts — please feel free to correct me if I'm misunderstanding anything.
For cluster operators: In practice, operators often need to look back at earlier failures, not just the last one. Since the system table is memory-based, it might be difficult to support historical tiering scheduling events. I'm also wondering if providing only the last failure via Flink SQL would be more convenient than manually checking Flink logs. I'm not sure if system tables would be the most suitable approach for operators, though they might be helpful in the future for viewing and managing tiering jobs. For end users: It seems they would primarily care about data freshness and scheduling priority, which would be quite convenient to access through system tables. The latency metrics are already well covered by Prometheus, so I'm curious about the specific scenarios where users would need the SQL interface for error information. These are just my initial thoughts. I'd appreciate your insights on the use cases you've encountered. Thank you in advance for your time. Best regards, Junbo Wang SeungMin Lee <[email protected]> 于2026年3月10日周二 15:47写道： > Hi devs, > I'd like to start a vote on FIP-30: Support tracking the tiering status of > a tiering table [1]. > > You can find the discussion on it in [2]. > This vote will last for at least 72 hours, unless there are objections or > insufficient votes. > > Best regards, > SeungMin Lee > > [1] > > https://cwiki.apache.org/confluence/display/FLUSS/FIP-30%3A+Support+tracking+the+tiering+status+of+a+tiering+table > [2] https://lists.apache.org/thread/9ljqmvnfjkktkgl0m6gp0c42nv8f0z1q >
