rakeshadr commented on pull request #2730: URL: https://github.com/apache/ozone/pull/2730#issuecomment-954441133
@bharatviswa504 thanks for the quick response. Added my response here: > I think now I am understanding the reason behind the proposal of setting to LEGACY, so that in fs the check will pass, and we donot need to update tests. Yes, this makes the existing test cases happy and these tests represents`new_client_1.2.0` FS operations. @JyotinderSingh please confirm. >Is there any other reason other than tests update, it will cause issues in real deployments? @bharatviswa504 In real deployments during upgrade phase both `old_client_1.1.0` and `new_client_1.2.0` can co-exists. Adding the strict bucket layout validation will fail the ofs/o3fs based customer applications and they need to re-write it their application while upgrading to newer software and ensure that all FS operations has to be done only on FSO buckets, right? Instead of changing the default value from OBS to LEGACY, I am thinking of introducing a client side flag **option-1)** `ozone.client.bucket.layout.validation=false`. By default we can set it to false and once the cluster is fully upgraded customer can set it to true that will enable the o3fs/ofs validation check. **option-2)** `ozone.client.bucket.layouts.allowed=FSO,OBS`. Here a comma-separated list of values where ofs/o3fs can do a validation check. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
