Correction: Vote is passed with 4 binding +1's (Uma, Marton, Xiaoyu and Arpit) and no -1. Thanks all for voting!
-Siyao On Tue, Jun 16, 2020 at 9:33 AM Siyao Meng <sm...@cloudera.com> wrote: > Vote is passed with 3 binding +1's (Uma, Marton, Xiaoyu) and no -1. > > Thank you all for voting! > > I will merge the feature branch to master in a day or two, after 1-2 more > test runs on PR #1021. > > -Siyao > > On Tue, Jun 16, 2020 at 9:30 AM Siyao Meng <sm...@cloudera.com> wrote: > >> Thanks Xiaoyu for the +1. >> >> - I have created a OFS user guide jira HDDS-3803. I'll add /tmp doc under >> that jira. >> - getTrashRoots(), which is a prerequisite of trash cleanup, will be done >> in HDDS-3705. >> - OFS ACL work tracking jira: HDDS-2991 >> - I'm working on the refactoring. One of the jira: HDDS-3805 >> >> -Siyao >> >> On Fri, Jun 12, 2020 at 11:25 AM Xiaoyu Yao <x...@cloudera.com.invalid> >> wrote: >> >>> Thanks Siyao for adding this useful feature. I reviewed several PRs on >>> the >>> feature branch >>> and feel positive to merge it master. Here are a few suggestions: >>> >>> 1. /tmp mount needs better document: >>> Anyone can create a bucket under global /tmp volume in addition to >>> their personal mounted /tmp when using o3 protocol? The two additional >>> /tmp >>> provision steps >>> seem to be different from using HDFS. We should document it clearly. >>> >>> 2. Some follow up work on trash clean up implementation on OM. That can >>> be >>> added after the merge. >>> >>> 3. Some missing features from both o3fs and ofs, such as ACL. This need >>> further discussion to >>> map HCFS acl to ozone acl. I'm OK with adding it post merge. >>> >>> 4. Some refactor work to dedup the FS implementation between ofs and >>> o3fs. >>> >>> Overall, I'm +1 on merge. >>> >>> Thanks, >>> Xiaoyu >>> >>> On Fri, Jun 12, 2020 at 12:02 AM Elek, Marton <e...@apache.org> wrote: >>> >>> > >>> > > Yes I admit there are quite a few duplicated lines of code. And this >>> is a >>> > > problem that needs to be solved sooner or later. >>> > > In the early stage of OFS development I discussed this with @Xiaoyu. >>> We >>> > > figured this could be resolved "later" -- which means now or soon >>> after >>> > > merge. >>> > > At that time (beginning of the feature branch) I was trying to touch >>> as >>> > few >>> > > existing classes as possible to minimize the conflict when rebasing >>> the >>> > > feature branch. This is also partially the reason for the >>> duplication. >>> > Also >>> > > the plan didn't work out as expected. >>> > >>> > Thanks to explain it. I am fine with doing it after a merge, if later >>> > means near-future/before the next release ;-) >>> > >>> > And I understand the motivation to keep the o3fs untouched, but I would >>> > like to encourage you: feel free to modify old code, too. >>> > >>> > >>> > >> We discussed in PR the BasicRootedOzoneFileSystem#adapterImpl can be >>> > > removed by exposing getVolume() in OzoneClientAdapter. >>> > > >>> https://github.com/apache/hadoop-ozone/pull/1021#discussion_r436749198 >>> > >>> > >>> > *ClientAdapters are created to separate OzoneClient/ObjectStore from >>> the >>> > OzoneFileSystem to make it possible to use the FilteredClassloader. >>> > >>> > As the classloader is removed we can consider to remove ClientAdapters, >>> > too (at least from the new code). I think some of my concerns are >>> rooted >>> > in the approach which tried to keep the previous structure. Again: feel >>> > free to do refactors if it makes it simpler / cleaner code. >>> > >>> > I also learned that the ClientProxy might be required to get better >>> > performance (ObjectStore/getVolume/getBucket executes a new GetBucket >>> > request all the time). >>> > >>> > As of now it is marked as @VisibleForTesting. We might need to remove >>> > the annotations and use it as now. >>> > >>> > >>> > Summary: I am fine with merging it to the master (it couldn't break >>> > anything), but I would prefer to continue the discussion and have an >>> > agreement what should we do before the next release... >>> > >>> > And I propose to run at least 4-5 builds in #1021 and analyze all the >>> > failures (!), before the merge (As I understood >>> > 2eb3181b552824ea8a5e5956387e4c8b540b97c9 from the #1021 is the proposed >>> > head to merge) >>> > >>> > Thanks, again, all the great work >>> > Marton >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: ozone-dev-unsubscr...@hadoop.apache.org >>> > For additional commands, e-mail: ozone-dev-h...@hadoop.apache.org >>> > >>> > >>> >>
