The idea sounds reasonable. Compatibility is an open question. We will have to bring this change through the upgrade framework since there will be changes to OM on-disk formats.
Upgrades and downgrades will be tricky IAC. It needs more thought. Thanks, Arpit > On Mar 11, 2021, at 9:52 AM, Uma gangumalla <umamah...@apache.org> wrote: > > Hi Devs, > > Currently as part of the client APIs, we have the parameters > ReplicationFactor and ReplicationType passed and based on that SCM, picks > the corresponding PipelineProvider and chooses the datanodes. > > Considering the ErasureCoding, it's hard to pass all of the EC related > parameters( example: data blocks number, parity blocks number etc) in > single class ReplicationFactor and it's not good idea to pass > multiple parameter and call the class name with "Factor" > > There is a proposal to introduce the ReplicationConfig: *HDDS-4882*: Introduce > the ReplicationConfig and modify the proto files > > I would like to bring this topic to the dev list to get everyone's > attention and feedback. The proposal is to deprecate the existing > ReplicationFactor and introduce ReplicationConfig. > > The respective replicationConfigs, like for Ratis: RatisReplicationConfig > and for EC: ECReplicationConfig. > > Thanks @Elek, Marton <e...@apache.org> for the JIRA and proposal. And It > would be great if you can put them into some class diagrams, so that it > will be helpful to understand batter. > > If we all agree for the proposal, we can push the ReplicationConfig, > RatisReplicationConfig changes to master itself. and later we will add only > ECReplicationConfig changes into the EC branch. This will help to reduce > the merge conflicts later. > > Thoughts? > > Regards, > Uma --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org For additional commands, e-mail: dev-h...@ozone.apache.org
