Okay, after some analysis I posted in https://github.com/apache/polaris/issues/2325#issuecomment-3208935604 I think it would be sufficient to fix-forward with a FeatureConfiguration determining whether to allow skipping the roleArn so that we can preserve fast-failure behavior in existing multi-tenant Polaris deployments.
In general we might need to add some better feature-gating of non-AWS S3-compat storage types; we can still make it easy to enable for self-deployed single-tenant Polaris but provide guardrails for shared deployments before 1.1 release. Longer term, I'd like to discuss ways to have more structured representations of S3-compat storage services to provide experiences both for those non-AWS services as well as keeping AWS-specific usability features for AWS. For example, if a single Polaris deployment needs to simultaneously interact with both AWS-S3 and non-AWS-S3-compat, then whether or not assumeRole indirection is used, we'd need different configurations for obtaining the base service-identity credentials depending on the StorageConfig being used. On Wed, Aug 20, 2025 at 8:15 PM Dennis Huo <huoi...@gmail.com> wrote: > Can we also highlight the key SPI and internal-API changes that service > providers with custom plugins should be aware/reminded of at a glance? > > In the future perhaps we can use a label or similar on SPI-evolution PRs > to better automate aggregating those changes, and also ideally also include > SPI changes as part of "proactive" CHANGELOG updates, possibly in a > different section from the other API/breaking-changes so that "vanilla" > Polaris users only need to look at changes to the public surface area, > while customized service-providers would benefit from the SPI evolution > section. > > Also I'm a bit confused about how > https://github.com/apache/polaris/pull/2329 "Make S3 roleARN optional" > works -- is it falling back to using the server-wide credentials? In any > case it needs to be FeatureConfiguration protected. It's also unclear how > it works when we still pass the empty roleArn into the AssumeRoleRequest. > > I'll follow up on the thread about making roleARN optional, but in the > meantime for 1.1 purposes we should earmark 2329 as a potential revert > until further discussion. > > On Wed, Aug 20, 2025 at 8:25 AM Dmitri Bourlatchkov > <dmitri.bourlatch...@dremio.com.invalid> wrote: > >> +1 to proactively updating CHANGELOG.md. >> >> That is how it was originally envisioned [1] :) >> >> [1] https://lists.apache.org/thread/qznf8toht1r7ml35lt4p8nwlk9op638v >> >> Cheers, >> Dmitri. >> >> On Wed, Aug 20, 2025 at 6:33 AM Robert Stupp <sn...@snazy.de> wrote: >> >> > Thanks a lot for tackling this, Pierre! >> > >> > It's very difficult to figure out all new features, changes and fixes >> > "after the fact". >> > >> > I think we should establish a culture to _proactively_ populate the >> > content of CHANGELOG.md _within_ each applicable PR instead of asking >> > weeks or months later, or having to figure out all the reasons and >> > come up with the "right" categorizations/descriptions/phrases. Doing >> > this kind of "archeological research" requires knowledge about all the >> > commits/PRs, their background, the implications, etc. This is >> > something that we cannot and should not expect from everybody. >> > >> > Having the CHANGELOG.md updated _in_ a PR makes it _much_ easier to >> > "backport" changes from the main branch to for example a `release/1.x` >> > branch or the like. >> > >> > On Wed, Aug 20, 2025 at 11:39 AM Pierre Laporte <pie...@pingtimeout.fr> >> > wrote: >> > > >> > > I just opened https://github.com/apache/polaris/pull/2406 with the >> list >> > of >> > > new features that were added in main since the 1.0.x release branch >> was >> > > cut. Would it be possible to get a review to ensure I did not miss >> any? >> > > >> > > Note that this only contains features, and not fixes. >> > > >> > > -- >> > > >> > > Pierre >> > > >> > > >> > > On Wed, Aug 20, 2025 at 12:25 AM Yufei Gu <flyrain...@gmail.com> >> wrote: >> > > >> > > > Hi JB, >> > > > >> > > > Make sense to move some enhancement and proposals to 1.2. e.g., >> > Support for >> > > > OpenLineage. Some of 1.1 items have been done, we could close them. >> I >> > haved >> > > > moved a few of them to 1.2. >> > > > >> > > > Meanwhile, can we have a list of new things shipped with 1.1.0? >> > > > >> > > > Yufei >> > > > >> > > > >> > > > On Tue, Aug 19, 2025 at 2:55 PM Dmitri Bourlatchkov < >> di...@apache.org> >> > > > wrote: >> > > > >> > > > > I'd like to merge [2401] before 1.1.0 due to Polaris behaviour >> > changes as >> > > > > noted in the PR. >> > > > > >> > > > > Please take a look. >> > > > > >> > > > > [2401] https://github.com/apache/polaris/pull/2401 >> > > > > >> > > > > Thanks, >> > > > > Dmitri. >> > > > > >> > > > > On Tue, Aug 19, 2025 at 3:28 PM Jean-Baptiste Onofré < >> > j...@nanthrax.net> >> > > > > wrote: >> > > > > >> > > > > > Hi folks, >> > > > > > >> > > > > > We currently have 18 issues on the 1.1.0 milestone: >> > > > > > >> > > > > > >> > > > > >> > > > >> > >> https://github.com/apache/polaris/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A1.1.0 >> > > > > > >> > > > > > As we are now starting to have monthly releases, I propose to >> bump >> > > > > > these GH issues with improvements and proposal labels to the >> 1.2.0 >> > > > > > milestone (1.2.0-incubating is planned for September). >> > > > > > Any objections? >> > > > > > >> > > > > > For the issues with the "bug" label, I don't see anything major >> > but I >> > > > > > would like to give a day for the community to take a look. >> > > > > > Can you please take a look at the GH issues with the 1.1.0 >> > milestone >> > > > > > to bump to 1.2.0 (or later) ? >> > > > > > Note that we can always include issues for 1.2.0 (September), >> 1.3.0 >> > > > > > (October), etc. We basically ship what we have :) >> > > > > > >> > > > > > I will do a new pass tomorrow. I would like to start the 1.1.0 >> > release >> > > > > > process by the end of this week. >> > > > > > >> > > > > > Thanks ! >> > > > > > >> > > > > > Regards >> > > > > > JB >> > > > > > >> > > > > >> > > > >> > >> >
