SaketaChalamchala opened a new pull request, #7750: URL: https://github.com/apache/ozone/pull/7750
## What changes were proposed in this pull request? 1. Setting the ozone.replication.type and ozone.replication configs to EC causes SCM to crash. This is because the BackgroundPipelineCreator does not skip pipeline creation when replication type is EC and tries to create an EC pipeline with HddsProtos.ReplicationFactor (ZERO, ONE, THREE) which is not supported. BackgroundPipelineCreator should not be creating EC pipelines. The proposed solution skips creating pipelines if ozone.replication.type is EC unless ozone.scm.pipeline.creation.auto.factor.one=true in which case, only RATIS ONE pipelines are created by BackgroundPipelineCreator. 2. The order of replication config resolution of key is not as expected causing existing acceptance tests to fail. Current order of key's replication config resolution is: 1. Replication config parameters passed from client during key create. 2. Replication config from client side configs if parameters are not passed. 3. Bucket replication config if client side parameters are not passed. 4. Server side default if bucket replication config is null. So, if ozone.replication.type is set to EC and a key is created in a bucket, the key is always created with EC replication regardless of whether the bucket's replication config is EC or RATIS. The same goes for if ozone.replication.type is set to RATIS. The expected order of replication config resolution for key should be: 1. Replication config parameters passed from client during key create. 2. Bucket replication config if client side parameters are not passed. 3. Server side default config if bucket replication config is null. So, this way key creation always used bucket replication configs unless replication config params are specifically passed through the client. It will default to server default replication config only if both key params and bucket replication config are null. 3. The order of replication config resolution of bucket is not as expected causing existing acceptance tests to fail. Current order of bucket's replication config resolution is 1. Replication config parameters passed from client during bucket create. 2. Server side default config if parameters are not passed. So, this means ozone.replication configs has no effect on bucket creation. You can set it to EC or RATIS but default bucket creation will always use the server default replication config. The proposed and I think expected order of bucket's replication config resolution should be 1. Replication config parameters passed from client during bucket create. 2. Replication config from client side configs if parameters are not passed. 3. Server side default if client side replication config is null. ## What is the link to the Apache JIRA https://issues.apache.org/jira/browse/HDDS-10336 ## How was this patch tested? Acceptance test. -- 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]
