Hi All, Heads up: I have reviewed and approved [3385], which completes the implementation of Anand's proposal.
If there are no fresh comments / concerns, I propose merging it before EOD Feb 20. [3385] https://github.com/apache/polaris/pull/3385 Cheers, Dmitri. On Tue, Feb 17, 2026 at 4:44 PM Anand Kumar Sankaran via dev < [email protected]> wrote: > Hi Dmitri, > > Thanks again. I have rebased [3385] against main. > > — > Anand > > From: Dmitri Bourlatchkov <[email protected]> > Date: Tuesday, February 17, 2026 at 12:11 PM > To: [email protected] <[email protected]> > Cc: Anand Kumar Sankaran <[email protected]> > Subject: Re: Polaris Telemetry and Audit Trail > > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious< > https://us-phishalarm-ewt.proofpoint.com/EWT/v1/Iz9xO38YGHZK!YhNDZAGr2cumYdvL-GeGN_sUtpf-vTAsw9ogTCTPGKCcS5ePHJr_UGiyUqgDQ5VNCl6xTwYj4qqUWwkvyuTh43tJ_AVdZJPgCLZDpZXbpB6L3jCaJL5OVoyRsNvKnAwL$ > > > > Hi Anand, > > PR [3523] (SQL schema) has been merged. > > Please rebase [3385]. > > [3523] https://github.com/apache/polaris/pull/3523< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3523__;!!Iz9xO38YGHZK!4sLrfIU8HUaeJshSZbprgWTwyaWUNAT-9Yof_YpVYP9T1Har02LkclV0s0wrDVe2-1tjesf_EfwLg5VWow$ > > > > [3385] https://github.com/apache/polaris/pull/3385< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3385__;!!Iz9xO38YGHZK!4sLrfIU8HUaeJshSZbprgWTwyaWUNAT-9Yof_YpVYP9T1Har02LkclV0s0wrDVe2-1tjesf_Efwsf7PUHQ$ > > > > Thanks, > Dmitri. > > On Fri, Feb 13, 2026 at 6:10 PM Dmitri Bourlatchkov <[email protected] > <mailto:[email protected]>> wrote: > Hi All, > > The SPI PR [3616] has been merged. > > I propose to merge the Schema PR [3523] on Mon if there are no objections > or fresh comments. > > [3616] https://github.com/apache/polaris/pull/3616< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3616__;!!Iz9xO38YGHZK!4sLrfIU8HUaeJshSZbprgWTwyaWUNAT-9Yof_YpVYP9T1Har02LkclV0s0wrDVe2-1tjesf_EfzzvX9eZQ$ > > > > [3523] https://github.com/apache/polaris/pull/3523< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3523__;!!Iz9xO38YGHZK!4sLrfIU8HUaeJshSZbprgWTwyaWUNAT-9Yof_YpVYP9T1Har02LkclV0s0wrDVe2-1tjesf_EfwLg5VWow$ > > > > Cheers, > Dmitri. > > > On Thu, Feb 12, 2026 at 6:00 PM Dmitri Bourlatchkov <[email protected] > <mailto:[email protected]>> wrote: > Hi All, > > The SPI PR [3616] for Scan/Commit metrics has been in review for 2 weeks > including 3 days in an approved state. > > Unless there are any last minute comments, I propose to merge it tomorrow > (Feb 13). > > [3616] https://github.com/apache/polaris/pull/3616< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3616__;!!Iz9xO38YGHZK!4sLrfIU8HUaeJshSZbprgWTwyaWUNAT-9Yof_YpVYP9T1Har02LkclV0s0wrDVe2-1tjesf_EfzzvX9eZQ$ > > > > Cheers, > Dmitri. > > On Mon, Feb 9, 2026 at 2:08 PM Anand Kumar Sankaran via dev < > [email protected]<mailto:[email protected]>> wrote: > Dmitri and others, > > Thanks for all the review feedback and being patient while we iterated. My > initial proposal was to persist the table metrics as events (least amount > of work 😊), we have come far from that proposal. > > To detach the SPI fully, there are a few things to do (loadSchemaVersion() > and shared DatasourceOperations). We can add a separate datasource config > to specify a different connection pool, perhaps. Can be done as a follow up > PR. > > — > Anand > > From: Dmitri Bourlatchkov <[email protected]<mailto:[email protected]>> > Date: Monday, February 9, 2026 at 10:52 AM > To: [email protected]<mailto:[email protected]> < > [email protected]<mailto:[email protected]>> > Cc: Anand Kumar Sankaran <[email protected]<mailto: > [email protected]>> > Subject: Re: Polaris Telemetry and Audit Trail > > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious< > https://us-phishalarm-ewt.proofpoint.com/EWT/v1/Iz9xO38YGHZK!YhNDZAGr2cumYduJ20ONMhMxljYPF8uZOe6R8BpEWyJ7tSG5GUUf8our05nYHWov0t1Vi7Rx_O8JuRNBBQQ57aBoctrR0wH7VSR9VxRuqYJPpz0q6I0JboPRfdLIwqal$ > > > > Hi Anand and all, > > Thanks for pushing this feature forward! From my POV the SPI [3616] and > the schema [3523] PRs are good to merge as the initial implementation of > this feature (annotated as "beta"). The way is open to the JDBC impl. PR > [3385] (which will probably need a rebase after merging the SPI and schema > code). > > I'm sending this email to highlight the direction taken with respect to > the SQL schema in this feature, as it might have been visible enough to the > broader community during the PR reviews. > > * The scan / commit metrics schema is managed / versioned separately from > the JDBC MetaStore schema > > * The Metrics Persistence SPI is detached (mostly at this time, but > supposedly fully detached later) from the JDBC MetaStore > > * The JDBC DataSource for metrics may be the same or different from the > MetaStore datasource. > > * Metrics Persistence may have non-JDBC implementation in the future (not > implemented ATM) > > * JDBC Metrics Persistence may co-exist with other MetaStore > implementations. > > I believe this design allows great flexibility for end users to try this > feature out and keeps options open for future enhancements in Scan / Commit > Metrics in Polaris. > > [3616] https://github.com/apache/polaris/pull/3616< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3616__;!!Iz9xO38YGHZK!4sLrfIU8HUaeJshSZbprgWTwyaWUNAT-9Yof_YpVYP9T1Har02LkclV0s0wrDVe2-1tjesf_EfzzvX9eZQ$ > >< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3616__;!!Iz9xO38YGHZK!7IwwfPXDN0ThhNZgol-n9Ww3FFLKcpZbSQ17lWEtcQnTHtJM9aVXnqGW99_6vmVkWACy7rYC8XEpN6Okdg$ > > > > [3523] https://github.com/apache/polaris/pull/3523< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3523__;!!Iz9xO38YGHZK!4sLrfIU8HUaeJshSZbprgWTwyaWUNAT-9Yof_YpVYP9T1Har02LkclV0s0wrDVe2-1tjesf_EfwLg5VWow$ > >< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3523__;!!Iz9xO38YGHZK!7IwwfPXDN0ThhNZgol-n9Ww3FFLKcpZbSQ17lWEtcQnTHtJM9aVXnqGW99_6vmVkWACy7rYC8XGOCHKhSg$ > > > > [3385] https://github.com/apache/polaris/pull/3385< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3385__;!!Iz9xO38YGHZK!4sLrfIU8HUaeJshSZbprgWTwyaWUNAT-9Yof_YpVYP9T1Har02LkclV0s0wrDVe2-1tjesf_Efwsf7PUHQ$ > >< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3385__;!!Iz9xO38YGHZK!7IwwfPXDN0ThhNZgol-n9Ww3FFLKcpZbSQ17lWEtcQnTHtJM9aVXnqGW99_6vmVkWACy7rYC8XFlxLMhvQ$ > > > > Thoughts / comments? > > Cheers, > Dmitri. > > > On Thu, Feb 5, 2026 at 6:50 PM Anand Kumar Sankaran via dev < > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>> wrote: > Hi Dmitri, > > Following up on your feedback regarding the metrics schema separation > approach. I've implemented the simplified design you suggested in > https://github.com/apache/polaris/pull/3523< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3523__;!!Iz9xO38YGHZK!4sLrfIU8HUaeJshSZbprgWTwyaWUNAT-9Yof_YpVYP9T1Har02LkclV0s0wrDVe2-1tjesf_EfwLg5VWow$ > >< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3523__;!!Iz9xO38YGHZK!7IwwfPXDN0ThhNZgol-n9Ww3FFLKcpZbSQ17lWEtcQnTHtJM9aVXnqGW99_6vmVkWACy7rYC8XGOCHKhSg$ > >: > > > The metrics schema can now evolve independently from the entity schema. > Let me know if you'd like any changes to this approach. > > Thanks, > Anand > > > > From: Dmitri Bourlatchkov <[email protected]<mailto:[email protected] > ><mailto:[email protected]<mailto:[email protected]>>> > Date: Thursday, February 5, 2026 at 2:57 PM > To: [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>> < > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>> > Cc: Anand Kumar Sankaran <[email protected]<mailto: > [email protected]><mailto:[email protected]<mailto: > [email protected]>>> > Subject: Re: Polaris Telemetry and Audit Trail > > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious< > https://us-phishalarm-ewt.proofpoint.com/EWT/v1/Iz9xO38YGHZK!YhNDZAGr2cumY1iAus5GNbkIxSXoQaI552sXgYyv7Z9Wrvb7qeTskSy5WkXTVDJ_Bel2AbNh_fQVn-HS_UtOSdOtpsNfzhXDkK4fYWdTeoeBe70A6oQVGpAYT3SrbEvs$ > > > > Hi Anand, > > Re: MetricsPersistence Factory - TBH I do not think it is required. If we > go with an MetricsPersistence impl. independent of the JDBC MetaStore, it > could be injected into PersistingMetricsReporter directly by CDI. > > Re: DataSource - for a start we could probably reuse the same DataSource > as the JDBS MetaStore uses. In principle, we could introduce a separate > DataSource, but I do not think we need to complicate the initial > implementation with that. It can be added later, if required. > > Re: schema / bootstrap - I'm thinking, indeed, of having a separate *.sql > file for metrics DDL. Then we could add an option to the bootstrap command > in the Admin Tool, or even a new command for creating / updating the > metrics schema. This might require some refactoring, but I believe the > bootstrap code needs some cleanup anyway. > > The general idea is to allow the metrics schema to evolve independently. > It's a new and actively developed feature, so having flexibility is going > to be good for making progress / improvements, I hope. > > Does that sound reasonable? > > Thanks, > Dmitri. > > On Thu, Feb 5, 2026 at 3:47 PM Anand Kumar Sankaran via dev < > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>>> wrote: > Hi Dmitri > > The SPI is designed to be pluggable via > MetaStoreManagerFactory.getOrCreateMetricsPersistence()< > https://github.com/apache/polaris/pull/3385/changes#diff-0e34667d083d30cace067936b87c736201e5a8cb001aa0b12e203ee52cddae99R51 > < > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3385/changes*diff-0e34667d083d30cace067936b87c736201e5a8cb001aa0b12e203ee52cddae99R51__;Iw!!Iz9xO38YGHZK!4sLrfIU8HUaeJshSZbprgWTwyaWUNAT-9Yof_YpVYP9T1Har02LkclV0s0wrDVe2-1tjesf_Efx9xKkRig$ > >< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3385/changes*diff-0e34667d083d30cace067936b87c736201e5a8cb001aa0b12e203ee52cddae99R51__;Iw!!Iz9xO38YGHZK!7IwwfPXDN0ThhNZgol-n9Ww3FFLKcpZbSQ17lWEtcQnTHtJM9aVXnqGW99_6vmVkWACy7rYC8XFxRr4qRw$ > >< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3385/changes*diff-0e34667d083d30cace067936b87c736201e5a8cb001aa0b12e203ee52cddae99R51__;Iw!!Iz9xO38YGHZK!_K1mcH0_2x0nbU-mZlbBi3tk9QAGjB6VInPiqkQU21mpIP_ft2bXXyIiADNoAcotNr9AKqlphh65taUhcw$>>. > The default returns MetricsPersistence.NOOP, and only JDBC with schema v4+ > returns a functional implementation. > > Your proposal makes sense to me. To allow NoSQL Entity Persistence + JDBC > Metrics Persistence would require: > > 1. Separate metrics schema files (e.g., metrics-schema-v1.sql) that > can be bootstrapped independently > 2. Separate datasource configuration for metrics (e.g., > polaris.metrics.jdbc.*) > 3. A dedicated `MetricsPersistenceFactory` interface (separate from > MetaStoreManagerFactory) > 4. Updates to the Admin Tool bootstrap workflow to handle both schemas > > Does that sound reasonable? If we do this, all this work should go into > https://github.com/apache/polaris/pull/3523< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3523__;!!Iz9xO38YGHZK!4sLrfIU8HUaeJshSZbprgWTwyaWUNAT-9Yof_YpVYP9T1Har02LkclV0s0wrDVe2-1tjesf_EfwLg5VWow$ > >< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3523__;!!Iz9xO38YGHZK!7IwwfPXDN0ThhNZgol-n9Ww3FFLKcpZbSQ17lWEtcQnTHtJM9aVXnqGW99_6vmVkWACy7rYC8XGOCHKhSg$ > >< > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3523__;!!Iz9xO38YGHZK!_K1mcH0_2x0nbU-mZlbBi3tk9QAGjB6VInPiqkQU21mpIP_ft2bXXyIiADNoAcotNr9AKqlphh4ZISZcDQ$> > as one atomic commit, correct? > > — > Anand > > > > From: Dmitri Bourlatchkov <[email protected]<mailto:[email protected] > ><mailto:[email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto: > [email protected]>>>> > Date: Thursday, February 5, 2026 at 8:28 AM > To: Anand Kumar Sankaran <[email protected]<mailto: > [email protected]><mailto:[email protected]<mailto: > [email protected]>><mailto:[email protected]<mailto: > [email protected]><mailto:[email protected]<mailto: > [email protected]>>>> > Cc: [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>> < > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>>> > Subject: Re: Polaris Telemetry and Audit Trail > > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious< > https://us-phishalarm-ewt.proofpoint.com/EWT/v1/Iz9xO38YGHZK!YhNDZAGr2cumbRcPlIOttKwvGr4f38TF-J2-LmOw8H1KsFpWaM3W5g28Oq5qW2gnw2-WHz0rsWhm7F7hSGykA9l01LKYGuCcCkexkHp1sUssM_IegCtjk_id9s891orv$ > > > > > Hi Anand, > > Thanks for driving the SPI definition for scan/commits metrics. > > I did not think from this angle before, but now I suppose it might be worth > introducing a separate SQL schema for metrics, detached from the main JDBC > Persistence schema. > > My rationale is that the SPI may be exercised independently of the JDBC > Entity Persistence. I can imagine people using NoSQL Entity Persistence > plus JDBC Scan Metrics Persistence in the same deployment. > > Using a separate schema will add further work on the Bootstrap workflow > (Admin Tool), but I hope the end result is going to be more convenient and > versatile for end users. > > WDYT? > > Thanks, > Dmitri. > > On Thu, Jan 29, 2026 at 1:49 PM Anand Kumar Sankaran < > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>>> wrote: > > > Hi Dmitri, > > > > Thank you for taking the time to review. I had pulled out the schema in > > its own PR (based on comments) here: > > > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3523__;!!Iz9xO38YGHZK!65BVFQDe_GtKbDW8LkNdzVS-WYewzWsSns5zFHKclbMU3vUy2UaTXLB5G-wql1yyqoTFyDc9Bt3GRsh6AA$ > > > > I will update the document with the SPI and carve out another PR that > > focuses on the SPI. > > > > — > > Anand > > > > *From: *Dmitri Bourlatchkov <[email protected]<mailto: > [email protected]><mailto:[email protected] > <mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected] > ><mailto:[email protected]<mailto: > [email protected]>>>> > > *Date: *Thursday, January 29, 2026 at 10:43 AM > > *To: *[email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>> < > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>>> > > *Cc: *Anand Kumar Sankaran <[email protected]<mailto: > [email protected]><mailto:[email protected]<mailto: > [email protected]>><mailto:[email protected]<mailto: > [email protected]><mailto:[email protected]<mailto: > [email protected]>>>> > > *Subject: *Re: Polaris Telemetry and Audit Trail > > > > This Message Is From an External Sender > > This message came from outside your organization. > > Report Suspicious > > < > https://us-phishalarm-ewt.proofpoint.com/EWT/v1/Iz9xO38YGHZK!YhNDZAGr2cumY1cAlUeoPrU2eNUPz9Wxq2PaG1t99vEN3v60gucxC3Qsk-xK09RndcW46WtNjMMjQZbaQ495h1D1g293F_uqLhPM8gDMlA6xRmo5b5uqrSh2v7QKHrhQ$ > > > > > > Hi Anand, > > > > Thanks for making a proposal doc and starting this thread. Apologies for > > late comments. > > > > As you know I already reviewed a couple of related PRs, which had a > > smaller impact on the codebase, but now, I believe, we're coming to the > > core of this feature and it might need a deeper discussion. > > > > For the sake of awareness of other project members, I'd like to > > highlight some aspects by email. > > > > * Storing scan metrics in RDBMS in general looks like a > > reasonable approach to me. However, Polaris Persistence is an extensible > > mechanism. Other backends are possible, including privately developed > > backends. > > > > From this POV, I believe it might be preferable to start not with an > RDBMS > > schema, but with a java SPI outlining expected read/write operations and > > the data model. This will make it easier to assess impact on other > > Persistence implementations. Naturally, Polaris service code will have to > > be able to work seamlessly regardless of the backend impl. (including the > > do-nothing impl.). > > > > I see that some connection between the SQL schema and java code is made > in > > PR [3385], but it does not appear to offer a clean SPI that could be > > implemented by different Persistence backends. Would it be ok from your > > perspective to make another PR with just SPI code? > > > > * Regarding ad-hoc SQL queries - it is certainly a valid use case for > > custom code to query the Polaris database directly. However, those ad-hoc > > queries may require certain indexes, which may not have a relevant use > case > > in OSS code. In that case, I believe it would be preferable to manage the > > extra indexes in custom code (not in Polaris). Whether this is the case > or > > not currently, I cannot say with certainty, so apologies if this is a > false > > alarm... Having the java SPI available would be a huge aid to reasoning > > about the proposed SQL schema, I think. > > > > That said, I do not mean to complicate the development of this feature, > > just trying to structure it in a way that is hopefully easy to understand > > (including myself), maintain and expand later. If I missed something, > > please feel free to point it out. > > > > [3385] > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3385__;!!Iz9xO38YGHZK!65BVFQDe_GtKbDW8LkNdzVS-WYewzWsSns5zFHKclbMU3vUy2UaTXLB5G-wql1yyqoTFyDc9Bt2W-eKl7A$ > > < > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3385__;!!Iz9xO38YGHZK!_dbBfwEnZEuPp_8qIuBDoYfWRgCZKiPDMg9ouDltqsHhr9hqCHVlF9IedSkNVBDWupbneU7inC9YK-THL-lTjWkkyZhI0OE$ > > > > > >Thanks, > > Dmitri. > > > > On Wed, Jan 14, 2026 at 10:05 PM Anand Kumar Sankaran via dev < > > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>>> wrote: > > > > Hi Yufei, > > > > Gave commenting privileges to all. > > > > Thanks. > > > > — > > Anand > > > > From: Yufei Gu <[email protected]<mailto:[email protected] > ><mailto:[email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>>> > > Date: Wednesday, January 14, 2026 at 6:13 PM > > To: [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>> < > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>>> > > Cc: Anand Kumar Sankaran <[email protected]<mailto: > [email protected]><mailto:[email protected]<mailto: > [email protected]>><mailto:[email protected]<mailto: > [email protected]><mailto:[email protected]<mailto: > [email protected]>>>> > > Subject: Re: Polaris Telemetry and Audit Trail > > > > This Message Is From an External Sender > > This message came from outside your organization. > > Report Suspicious< > > > https://us-phishalarm-ewt.proofpoint.com/EWT/v1/Iz9xO38YGHZK!YhNDZABkHi1B6hyPVYUK0T-K5j4Aoqdrlu07UjBpJcpjOsz7Ie7d_DhPl-ywi50dfQz4O6LL-AHLCOQTQ0X7Le8yD2cF0ogquGFB8Aw8uQLgB0RL6Ezpa-pLDPA4ziXA$ > > > > > > > Hi Anand, thanks for the design doc and PR. Can you allow comments in the > > doc so that people can chime in? Thanks! > > > > Yufei > > > > > > On Sat, Jan 10, 2026 at 9:09 AM Anand Kumar Sankaran via dev < > > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>><mailto: > [email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>>>> wrote: > > Hi all > > > > My first PR for adding AWS STS Session Tags support for credential > vending > > was merged. > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3327__;!!Iz9xO38YGHZK!65BVFQDe_GtKbDW8LkNdzVS-WYewzWsSns5zFHKclbMU3vUy2UaTXLB5G-wql1yyqoTFyDc9Bt0YHY9sdA$ > > < > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3327__;!!Iz9xO38YGHZK!_dbBfwEnZEuPp_8qIuBDoYfWRgCZKiPDMg9ouDltqsHhr9hqCHVlF9IedSkNVBDWupbneU7inC9YK-THL-lTjWkklJ4Xf9Y$ > > > >< > > > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3327__;!!Iz9xO38YGHZK!8vlQ2_OqjmZNIpbrTTluFFNKFCEeM87nr95MP5pMpMu5fFWVSoBZ3eb6-C2xbAGCG-ry5eaCO-pFLxl3IZAJGqY$ > >> > > > > I have been working with Prashant on an end-to-end telemetry and audit > > trail tracking for Polaris. It is documented here. > > > https://urldefense.com/v3/__https://docs.google.com/document/d/1Ehzvi5RNPs4hChkBFI6VD23myEqm-7sWW3d2kjmuYj8/edit?tab=t.0__;!!Iz9xO38YGHZK!65BVFQDe_GtKbDW8LkNdzVS-WYewzWsSns5zFHKclbMU3vUy2UaTXLB5G-wql1yyqoTFyDc9Bt11Y1rbNQ$ > > < > https://urldefense.com/v3/__https://docs.google.com/document/d/1Ehzvi5RNPs4hChkBFI6VD23myEqm-7sWW3d2kjmuYj8/edit?tab=t.0__;!!Iz9xO38YGHZK!_dbBfwEnZEuPp_8qIuBDoYfWRgCZKiPDMg9ouDltqsHhr9hqCHVlF9IedSkNVBDWupbneU7inC9YK-THL-lTjWkk8MVJPlY$ > > > >< > > > https://urldefense.com/v3/__https://docs.google.com/document/d/1Ehzvi5RNPs4hChkBFI6VD23myEqm-7sWW3d2kjmuYj8/edit?tab=t.0__;!!Iz9xO38YGHZK!8vlQ2_OqjmZNIpbrTTluFFNKFCEeM87nr95MP5pMpMu5fFWVSoBZ3eb6-C2xbAGCG-ry5eaCO-pFLxl3hYqTlcg$ > >> > > > > Based on Prashant’s initial feedback (parity with Apache Gravitino for > > metrics reports), I have an initial PR here. > > > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3385__;!!Iz9xO38YGHZK!65BVFQDe_GtKbDW8LkNdzVS-WYewzWsSns5zFHKclbMU3vUy2UaTXLB5G-wql1yyqoTFyDc9Bt2W-eKl7A$ > > < > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3385__;!!Iz9xO38YGHZK!_dbBfwEnZEuPp_8qIuBDoYfWRgCZKiPDMg9ouDltqsHhr9hqCHVlF9IedSkNVBDWupbneU7inC9YK-THL-lTjWkkyZhI0OE$ > > > >< > > > https://urldefense.com/v3/__https://github.com/apache/polaris/pull/3385__;!!Iz9xO38YGHZK!8vlQ2_OqjmZNIpbrTTluFFNKFCEeM87nr95MP5pMpMu5fFWVSoBZ3eb6-C2xbAGCG-ry5eaCO-pFLxl39opCznI$ > >> > > > > I will be reaching out to various folks for review. I am open to breaking > > down the PR into smaller logical groups of PR if it helps. > > > > I request you to look at the Google doc and let me know what you think. > > > > — > > Anand > > > > > > > > -- > > Dmitri Bourlatchkov > > Senior Staff Software Engineer, Dremio > > Dremio.com > > < > https://urldefense.com/v3/__https://www.dremio.com/?utm_medium=email&utm_source=signature&utm_term=na&utm_content=email-signature&utm_campaign=email-signature__;!!Iz9xO38YGHZK!_dbBfwEnZEuPp_8qIuBDoYfWRgCZKiPDMg9ouDltqsHhr9hqCHVlF9IedSkNVBDWupbneU7inC9YK-THL-lTjWkkiOwjJc0$ > >/ > > Follow Us on LinkedIn > > < > https://urldefense.com/v3/__https://www.linkedin.com/company/dremio__;!!Iz9xO38YGHZK!_dbBfwEnZEuPp_8qIuBDoYfWRgCZKiPDMg9ouDltqsHhr9hqCHVlF9IedSkNVBDWupbneU7inC9YK-THL-lTjWkkCLjBQ2M$ > >/ > > Get Started > > < > https://urldefense.com/v3/__https://www.dremio.com/get-started/__;!!Iz9xO38YGHZK!_dbBfwEnZEuPp_8qIuBDoYfWRgCZKiPDMg9ouDltqsHhr9hqCHVlF9IedSkNVBDWupbneU7inC9YK-THL-lTjWkkoKQUMII$ > > > > > > > >The Agentic Lakehouse > > *The only lakehouse built for agents, managed by agents* > > > > > > > >
