Is adding custom archival provider a hack?

Community Support
1

Requirement
I am archiving workflows to s3. However its an inhouse s3 and doesn’t support bucket operations
I want to disable bucket URI validation which happens at the time of namespace creation.

Approach 1
Comment out the bucket validation line in the existing s3 provider (line 349 in historyArchiver.go & line 269 in visibilityArchiver.go)

Approach 2
Write a new provider (exact as s3 one, but with the bucket validation commented out). Follow the steps in the archival documentation to config the new custom provider. Which involves editing /common/archiver/provider/provider.go and a few other files.

What’s the problem?
In both approaches, I’m modifying the temporal files, and risking a break when I upgrade to a higher version of temporal involving a change to these files?

Question

  1. Which approach should I take?
2

I understand that currently both approaches would force you to make changes outside of configuration which is not optimal. Right now I would go with approach 2 as imo regardless of what changes are done to archival in the future, users should still be able to register custom provider.

One thing that imo would be beneficial is if you (I can help you with it as well) start opening issues in temporal server repo about all the things you see are needed or new features that you would like to see added for archival in the future. I think your input after all the work you have done in this area would be really beneficial to have.