elek commented on pull request #1270: URL: https://github.com/apache/hadoop-ozone/pull/1270#issuecomment-666318907
> More flexibility usually comes with more complexity. :) In general, I can agree with this statement, but in this specific case: the additional complexity of one configuration key seems to be minimal. > The example Bharat highlighted seems valid - different S3 gateways using a different config key. I think in the future we can support volume level links which will allow pointing /s3g to /home. I am also in favor of at least making this config key undocumented to discourage its use. *"Different S3 gateways using a different config key"* --> It's also a feature which can be used in some specific cases. But I agree, flexibility vs complexity can be a balance. Sometimes It can be hard to choose between them without being opinionated. Here, I feel I have two different views: When it's part of an open source project: I would prefer to keep the project flexible (within boundaries !!!) but use smart defaults. When it's part of distribution of a vendor: I see it more reasonable to restrict specific usage patterns. But these restrictions can be specific a usage (vendor/distribution) and others may use the open source project in a different way. But again, it's more like a philosophy, hard to use *technical* arguments here. If you really like to remove the documentation of this configuration (It means to remove the 3rd sentence from here: https://github.com/apache/hadoop-ozone/blob/master/hadoop-hdds/docs/content/interface/S3.md, I guess), let's do that. (I am +0 about changing only the docs: I don't like it, but I can accept it if it's your strong opinion) In general, I prefer to explain the risk and teach the user, instead of hiding information. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
