+1 for the merge. Thanks Mukul Kumar Singh <mksingh.apa...@gmail.com> 于2022年4月7日周四 14:05写道：
> +1 for the merge. > > > Thanks Lokesh > > On 07/04/22 11:29 am, Lokesh Jain wrote: > > +1 for merge > > > > Thanks > > Lokesh > > > >> On 07-Apr-2022, at 11:06 AM, Tsz Wo Sze <szets...@gmail.com> wrote: > >> > >> +1 > >> We should merge it so that more people can try it. We can work on the > >> remaining tasks in the master branch. Thanks a lot! > >> > >> Tsz-Wo > >> > >> On Thu, Apr 7, 2022 at 1:17 PM Aravindan Vijayan > >> <avija...@cloudera.com.invalid> wrote: > >> > >>> +1 for the merge. Thanks for the great work! > >>> > >>> > >>> > >>> On Wed, Apr 6, 2022 at 9:45 PM Prashant Pogde > <ppo...@cloudera.com.invalid > >>> wrote: > >>> > >>>> +1 for the EC branch merge. > >>>> > >>>> Regards, > >>>> Prashant > >>>> > >>>>> On Apr 6, 2022, at 8:20 PM, Siddharth Wagle <swa...@apache.org> > wrote: > >>>>> > >>>>> +1 for the EC branch merge. > >>>>> > >>>>> Best, > >>>>> Sid > >>>>> > >>>>> On Wed, Apr 6, 2022 at 8:05 PM guimark <guim...@126.com> wrote: > >>>>> > >>>>>> Great news! > >>>>>> +1 to merge. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> At 2022-04-06 22:18:31, "Stephen O'Donnell" <sodonn...@cloudera.com > >>>> .INVALID> > >>>>>> wrote: > >>>>>>> I have been working on the code on this branch for some time, and I > >>>>>> believe > >>>>>>> it is in a good state to merge now. It is mostly new code, and if > >>>> nothing > >>>>>>> attempts to use EC, none of the EC code paths will be executed. > >>>>>>> > >>>>>>> +1 to merge from me. > >>>>>>> > >>>>>>> Stephen. > >>>>>>> > >>>>>>> On Wed, Apr 6, 2022 at 7:11 AM Uma gangumalla < > umamah...@apache.org> > >>>>>> wrote: > >>>>>>>> =====Few Edits Below=================== > >>>>>>>> > >>>>>>>> Dear Ozone Devs, > >>>>>>>> > >>>>>>>> As you may know, we have been actively developing Ozone Erasure > >>> Coding > >>>>>>>> support in a separate branch HDDS-3816-ec. > >>>>>>>> > >>>>>>>> We have finished the development of EC key write and read > >>>> functionality. > >>>>>>>> The support of offline recovery( Recovering replica from node > loss) > >>>>>> will be > >>>>>>>> part of second phase work. > >>>>>>>> > >>>>>>>> Since the code has already grown and increasingly started seeing > >>> merge > >>>>>>>> complications, we would like to merge the current EC branch into > >>>> master. > >>>>>>>> We filed the new JIRA(HDDS-6462) for the second phase of work and > >>>>>> continued > >>>>>>>> the offline recovery work there. (we have uploaded the design doc > >>>> there) > >>>>>>>> Details on Changes: > >>>>>>>> > >>>>>>>> - > >>>>>>>> > >>>>>>>> Most of the EC core logic went to newly extended classes. Key > >>>> changes > >>>>>>>> went into EC*OutputStream and EC*InputStream classes for write > and > >>>>>> read > >>>>>>>> respectively. Based on replication type, ECPipelineProvider will > >>> be > >>>>>>>> chosen > >>>>>>>> for creating EC pipelines. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> - > >>>>>>>> > >>>>>>>> Since we cannot represent the EC replication in the existing > >>>>>> replication > >>>>>>>> factor, we have introduced ECReplicationConfig. The > >>>> ReplicationConfig > >>>>>>>> interface is already pushed to master, so it’s not a new idea > >>> coming > >>>>>>>> through this branch merge now. What is newly coming here is the > >>>>>>>> ECReplicationConfig class which can be used to express EC > >>>> replication > >>>>>>>> configuration. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> - > >>>>>>>> > >>>>>>>> We wanted to provide the support to enable EC at bucket level. > To > >>>>>>>> simplify some complications, we have moved the default > replication > >>>>>>>> configurations from client to server. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> - > >>>>>>>> > >>>>>>>> Client side replication type and replication factor removed from > >>> the > >>>>>>>> configuration files and introduced the > >>>>>> ozone.server.default.replication > >>>>>>>> and ozone.server.default.replication.type.We would continue to > >>>>>> respect > >>>>>>>> if > >>>>>>>> one configures at client side explicitly or passed through APIs, > >>>>>>>> otherwise > >>>>>>>> server side bucket level properties or server side default > >>>>>> configuration > >>>>>>>> would take effect. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> - > >>>>>>>> > >>>>>>>> Other than this change, the rest of EC side code should not > impact > >>>>>> any > >>>>>>>> of the existing code flows. > >>>>>>>> > >>>>>>>> > >>>>>>>> We have finished documentation JIRA(HDDS-6172) for covering this > >>>> feature > >>>>>>>> and we will continue to improve further in master. > >>>>>>>> > >>>>>>>> Git Branch Name : HDDS-3816-ec > >>>>>>>> > >>>>>>>> JIRAs: HDDS-3816 and HDDS-5351 > >>>>>>>> > >>>>>>>> Completed tasks: ~ 142 > >>>>>>>> > >>>>>>>> + We are covering the following two mandatory JIRAs to come in: > >>>>>>>> > >>>>>>>> 1. HDDS-6209: EC: [Forward compatibility issue] New client to > older > >>>>>> server > >>>>>>>> could fail due to the unavailability for client default > replication > >>>>>> config > >>>>>>>> 2. HDDS-5909: EC: Onboard EC into upgrade framework. > >>>>>>>> > >>>>>>>> PRs reviews in-progress and expected to close in a day or two. > >>>>>>>> > >>>>>>>> Few other JIRAs in HDDS-3816 are still open but I believe they're > >>> not > >>>>>>>> blockers for merge. > >>>>>>>> > >>>>>>>> In short what you can do now with this feature: > >>>>>>>> > >>>>>>>> - > >>>>>>>> > >>>>>>>> You can enable EC at bucket level and cluster level. > >>>>>>>> > >>>>>>>> How to enable it at bucket level? Just create the bucket by > passing > >>>> the > >>>>>> ec > >>>>>>>> replication options. > >>>>>>>> > >>>>>>>> - > >>>>>>>> > >>>>>>>> You can create EC keys and read the same back. > >>>>>>>> - > >>>>>>>> > >>>>>>>> You should be able to continue writing even when chosen nodes > are > >>>>>>>> failing. (Of Course minimum of Data+Parity live nodes should be > >>>>>>>> available > >>>>>>>> in cluster for complete the write) > >>>>>>>> - > >>>>>>>> > >>>>>>>> You should be able to read the file back even if a few nodes > >>> failed > >>>>>> in > >>>>>>>> the same ec block group(Failures should not be more than parity > >>>>>> number > >>>>>>>> of > >>>>>>>> nodes.). > >>>>>>>> > >>>>>>>> What is pending? Offline recovery of lost/missing EC containers. > As > >>>>>>>> mentioned above, post merge of this branch, I will create a > separate > >>>>>> JIRA > >>>>>>>> for starting the work for OfflineRecovery. > >>>>>>>> > >>>>>>>> > >>>>>>>> There are automated acceptance test cases already added. HDDS-6231 > >>>>>>>> > >>>>>>>> In addition to that, we have also performed basic Acceptance > Testing > >>>> in > >>>>>>>> physical cluster: > >>>>>>>> > >>>>>>>> 1. > >>>>>>>> > >>>>>>>> Installed 10 nodes cluster and created EC bucket (3:2). > >>>>>>>> > >>>>>>>> Uploaded 10GB key. > >>>>>>>> > >>>>>>>> Downloaded the same key and checked the md5sum. > >>>>>>>> > >>>>>>>> 1. > >>>>>>>> > >>>>>>>> Uploaded 8GB key. > >>>>>>>> > >>>>>>>> Downloaded the same key and checked the md5sum. > >>>>>>>> > >>>>>>>> 1. > >>>>>>>> > >>>>>>>> Uploaded 3MB key > >>>>>>>> > >>>>>>>> Downloaded the same and verified md5sum. > >>>>>>>> > >>>>>>>> 1. > >>>>>>>> > >>>>>>>> Changed bucket to (6:3) > >>>>>>>> > >>>>>>>> Uploaded 8GB key > >>>>>>>> > >>>>>>>> Download the same. > >>>>>>>> > >>>>>>>> Also verified the new key should be in 6:3 policy and old keys > must > >>> be > >>>>>>>> 3:2.Verified > >>>>>>>> with several different size key writes and reads. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Since the merge discussion thread, we have well stabilized code > and > >>>>>> fixed > >>>>>>>> several bugs. > >>>>>>>> > >>>>>>>> > >>>>>>>> Merge checklist items assessment is here: > >>>>>>>> > >>>>>>>> > >>> > https://cwiki.apache.org/confluence/display/OZONE/Ozone+EC+Branch%28HDDS-3816-ec%29+Phase-1+%3A+Merge+Checklist > >>>>>>>> Big shoutout to Stephen O'Donnell <sodonn...@cloudera.com>, > Istvan > >>>>>> Fajth > >>>>>>>> <pi...@cloudera.com> for great efforts in core development and > also > >>>>>> thanks > >>>>>>>> a lot to Sammi, Mingchao Zhao, Mark Gui, Kaijie, Attila for > >>>>>> collaborating > >>>>>>>> on some of the EC tasks. > >>>>>>>> > >>>>>>>> Thanks to Marton for design discussion and on some dev tasks as > >>> well. > >>>>>>>> Thanks to many others who were involved in design discussions, > >>> Arpit, > >>>>>> Sidd, > >>>>>>>> Jitendra, Mukul, Sanjay, Karthik, Bharat, Nanda, Shashi, > Prashanth, > >>>>>> Rakesh, > >>>>>>>> Yiqun Lin. > >>>>>>>> Sorry if I miss anyone here, but your efforts are much > appreciated. > >>>>>> Without > >>>>>>>> your tremendous help, we would have not reached this position yet. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> To start with, here is my +1 > >>>>>>>> > >>>>>>>> The vote will run for 5 days. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Uma > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Tue, Apr 5, 2022 at 10:58 PM Uma gangumalla < > >>> umamah...@apache.org> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Dear Ozone Devs, > >>>>>>>>> > >>>>>>>>> As you may know, we have been actively developing Ozone Erasure > >>>> Coding > >>>>>>>>> support in a separate branch HDDS-3816-ec. > >>>>>>>>> > >>>>>>>>> We have finished the development of EC key write and read > >>>>>> functionality. > >>>>>>>>> The support of offline recovery( Recovering replica from node > loss) > >>>>>> will > >>>>>>>> be > >>>>>>>>> part of second phase work. > >>>>>>>>> > >>>>>>>>> Since the code has already grown and increasingly started seeing > >>>> merge > >>>>>>>>> complications, we would like to propose to merge the current EC > >>>> branch > >>>>>>>> into > >>>>>>>>> master. > >>>>>>>>> > >>>>>>>>> We filed the new JIRA(HDDS-6462) for the second phase of work and > >>>>>>>>> continued the offline recovery work there. > >>>>>>>>> > >>>>>>>>> Details on Changes: > >>>>>>>>> > >>>>>>>>> - > >>>>>>>>> > >>>>>>>>> Most of the EC core logic went to newly extended classes. Key > >>>>>> changes > >>>>>>>>> went into EC*OutputStream and EC*InputStream classes for write > >>> and > >>>>>>>> read > >>>>>>>>> respectively. Based on replication type, ECPipelineProvider > will > >>> be > >>>>>>>> chosen > >>>>>>>>> for creating EC pipelines. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> - > >>>>>>>>> > >>>>>>>>> Since we cannot represent the EC replication in the existing > >>>>>>>>> replication factor, we have introduced ECReplicationConfig. The > >>>>>>>>> ReplicationConfig interface is already pushed to master, so > it’s > >>>>>> not > >>>>>>>> a new > >>>>>>>>> idea coming through this branch merge now. What is newly coming > >>>>>> here > >>>>>>>> is the > >>>>>>>>> ECReplicationConfig class which can be used to express EC > >>>>>> replication > >>>>>>>>> configuration. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> - > >>>>>>>>> > >>>>>>>>> We wanted to provide the support to enable EC at bucket level. > To > >>>>>>>>> simplify some complications, we have moved the default > >>> replication > >>>>>>>>> configurations from client to server. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> - > >>>>>>>>> > >>>>>>>>> Client side replication type and replication factor removed > from > >>>>>> the > >>>>>>>>> configuration files and introduced the > >>>>>>>> ozone.server.default.replication > >>>>>>>>> and ozone.server.default.replication.type.We would continue to > >>>>>>>> respect if > >>>>>>>>> one configures at client side explicitly or passed through > APIs, > >>>>>>>> otherwise > >>>>>>>>> server side bucket level properties or server side default > >>>>>>>> configuration > >>>>>>>>> would take effect. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> - > >>>>>>>>> > >>>>>>>>> Other than this change, the rest of EC side code should not > >>> impact > >>>>>> any > >>>>>>>>> of the existing code flows. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> We have finished documentation JIRA(HDDS-6172) for covering this > >>>>>> feature > >>>>>>>>> and we will continue to improve further in master. > >>>>>>>>> > >>>>>>>>> Git Branch Name : HDDS-3816-ec > >>>>>>>>> > >>>>>>>>> JIRAs: HDDS-3816 and HDDS-5351 > >>>>>>>>> > >>>>>>>>> Completed tasks: ~ 142 > >>>>>>>>> > >>>>>>>>> + We are covering the following two mandatory JIRAs: > >>>>>>>>> > >>>>>>>>> 1. HDDS-6209: EC: [Forward compatibility issue] New client to > older > >>>>>>>>> server could fail due to the unavailability for client default > >>>>>>>> replication > >>>>>>>>> config > >>>>>>>>> > >>>>>>>>> 2. HDDS-5909: EC: Onboard EC into upgrade framework. > >>>>>>>>> > >>>>>>>>> PRs reviews in-progress and expected to close in a day or two. > >>>>>>>>> > >>>>>>>>> Few other JIRAs in HDDS-3816 are still open but I believe they're > >>> not > >>>>>>>>> blockers for merge. > >>>>>>>>> > >>>>>>>>> In short what you can do now with this feature: > >>>>>>>>> > >>>>>>>>> - > >>>>>>>>> > >>>>>>>>> You can enable EC at bucket level and cluster level. > >>>>>>>>> > >>>>>>>>> How to enable it at bucket level? Just create the bucket by > passing > >>>>>> the > >>>>>>>> ec > >>>>>>>>> replication options. > >>>>>>>>> > >>>>>>>>> - > >>>>>>>>> > >>>>>>>>> You can create EC keys and read the same back. > >>>>>>>>> - > >>>>>>>>> > >>>>>>>>> You should be able to continue writing even when chosen nodes > are > >>>>>>>>> failing. (Of Course minimum of Data+Parity live nodes should be > >>>>>>>> available > >>>>>>>>> in cluster for complete the write) > >>>>>>>>> - > >>>>>>>>> > >>>>>>>>> You should be able to read the file back even if a few nodes > >>>>>> failed in > >>>>>>>>> the same ec block group(Failures should not be more than parity > >>>>>>>> number of > >>>>>>>>> nodes.). > >>>>>>>>> > >>>>>>>>> What is pending? Offline recovery of lost/missing EC containers. > As > >>>>>>>>> mentioned above, post merge of this branch, I will create a > >>> separate > >>>>>> JIRA > >>>>>>>>> for starting the work for OfflineRecovery. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> There are automated acceptance test cases already added. > HDDS-6231 > >>>>>>>>> > >>>>>>>>> In addition to that, we have also performed basic Acceptance > >>> Testing > >>>>>> in > >>>>>>>>> physical cluster: > >>>>>>>>> > >>>>>>>>> 1. > >>>>>>>>> > >>>>>>>>> Installed 10 nodes cluster and created EC bucket (3:2). > >>>>>>>>> > >>>>>>>>> Uploaded 10GB key. > >>>>>>>>> > >>>>>>>>> Downloaded the same key and checked the md5sum. > >>>>>>>>> > >>>>>>>>> 1. > >>>>>>>>> > >>>>>>>>> Uploaded 8GB key. > >>>>>>>>> > >>>>>>>>> Downloaded the same key and checked the md5sum. > >>>>>>>>> > >>>>>>>>> 1. > >>>>>>>>> > >>>>>>>>> Uploaded 3MB key > >>>>>>>>> > >>>>>>>>> Downloaded the same and verified md5sum. > >>>>>>>>> > >>>>>>>>> 1. > >>>>>>>>> > >>>>>>>>> Changed bucket to (6:3) > >>>>>>>>> > >>>>>>>>> Uploaded 8GB key > >>>>>>>>> > >>>>>>>>> Download the same. > >>>>>>>>> > >>>>>>>>> Also verified the new key should be in 6:3 policy and old keys > must > >>>> be > >>>>>>>> 3:2.Verified > >>>>>>>>> with several different size key writes and reads. > >>>>>>>>> > >>>>>>>>> Merge checklist items assessment is here: > >>>>>>>>> > >>> > https://cwiki.apache.org/confluence/display/OZONE/Ozone+EC+Branch%28HDDS-3816-ec%29+Phase-1+%3A+Merge+Checklist > >>>>>>>>> Big shoutout to Stephen O'Donnell <sodonn...@cloudera.com>, > Istvan > >>>>>> Fajth > >>>>>>>>> <pi...@cloudera.com> for great efforts in core development and > >>> also > >>>>>>>>> thanks a lot to Sammi, Mingchao Zhao, Mark Gui, Kaijie for > >>>>>> collaborating > >>>>>>>>> on some of the EC tasks. > >>>>>>>>> > >>>>>>>>> Thanks to Marton for design discussion and on some dev tasks as > >>> well. > >>>>>>>>> Thanks to many others who were involved in design discussions, > >>> Arpit, > >>>>>>>>> Sidd, Jitendra, Mukul, Sanjay, Karthik, Bharat, Nanda, Shashi, > >>>>>> Prashanth, > >>>>>>>>> Rakesh, Yiqun Lin. > >>>>>>>>> Sorry if I miss anyone here, but your efforts are much > appreciated. > >>>>>>>>> Without your tremendous help, we would have not reached this > >>> position > >>>>>>>> yet. > >>>>>>>>> If there are no objections for the merge, I will start the > official > >>>>>> vote > >>>>>>>>> later. > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> > >>>>>>>>> EC Branch Devs > >>>>>>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org > >>>> For additional commands, e-mail: dev-h...@ozone.apache.org > >>>> > >>>> > >>> -- > >>> Thanks & Regards, > >>> Aravindan > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org > > For additional commands, e-mail: dev-h...@ozone.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org > For additional commands, e-mail: dev-h...@ozone.apache.org > >
