Re: [VOTE] Apache Hadoop Ozone 1.0.0 RC1

[Jitendra Pandey]

+1 (binding)

1. Verified signatures
2. Built from source
3. deployed with docker
4. tested with basic s3 apis.

On Tue, Aug 25, 2020 at 7:01 AM Sammi Chen  wrote:

> RC1 artifacts are at:
> https://home.apache.org/~sammichen/ozone-1.0.0-rc1/
> 
>
> Maven artifacts are staged at:
> https://repository.apache.org/content/repositories/orgapachehadoop-1278
> 
>
> The public key used for signing the artifacts can be found at:
> https://dist.apache.org/repos/dist/release/hadoop/common/KEYS
>
> The RC1 tag in github is at:
> https://github.com/apache/hadoop-ozone/releases/tag/ozone-1.0.0-RC1
> 
>
> Change log of RC1, add
> 1. HDDS-4063. Fix InstallSnapshot in OM HA
> 2. HDDS-4139. Update version number in upgrade tests.
> 3. HDDS-4144, Update version info in hadoop client dependency readme
>
> *The vote will run for 7 days, ending on Aug 31th 2020 at 11:59 pm PST.*
>
> Thanks,
> Sammi Chen
>

Re: [DISCUSS] Ozone TLP proposal, final draft

[Jitendra Pandey]

Thanks Marton for the proposal, this looks pretty good, and well thought
out.
I also agree with Arpit, that we should also include folks, who are not
hadoop PMC, but have been actively making significant contributions to
Ozone as committers.
I am +1 for everyone in the currently proposed PMC list, and would
suggest to also include hadoop committers who have committed 10 or more
patches since Jan, 2020. This should cover the active committers who are
already driving the project and deserve to be in PMC.


Thanks
jitendra



On Wed, Aug 26, 2020 at 5:50 PM Arpit Agarwal 
wrote:

> The list excludes folks who have been active on Ozone for over 1 year with
> significant design contributions and patch counts in the high double
> digits. They'd merit being on the project PMC by any objective basis so it
> was likely an unintentional oversight.
>
> There are a couple of options:
>
> 1. Include long-time contributors in the initial list. I've made a few
> edits to the list in the proposal. Please make further edits if I missed
> anyone.
>
> 2. Restrict the initial PMC to Hadoop PMC members, and once the TLP is
> formed let's elect the folks left out at the start with priority. At least
> that avoids the obvious perception of unfairness.
>
> My vote is for #1, let's not be another Hadoop.
>
> Thanks,
> Arpit
>
>
> On 8/26/20, 4:05 AM, "Elek, Marton"  wrote:
>
> Hi all,
>
> Ozone TLP proposal is updated with the proposed project membership
> list.
>
> The initial list is based on pure statistical data from Jira (HDDS and
> HDFS-7240 sub issues, hadoop-ozone/hadoop/hadoop-docker-ozone git
> contributions) all active Hadoop PMC members/committers/contributors
> are
> added to the list.
>
> As earlier discussed, it’s important to acknowledge non-code
> contributions. Therefore, I asked everybody on the initial list (which
> is based contributions) to suggest more people, to make sure,
> everybody
> is included who can help us to make Ozone successful. Thanks to the
> feedback additional people to make Ozone even stronger:
>
> Matt and Clay are regular members of the community meetings and design
> discussion, they helped a lot with design decisions and helping to
> choose the right direction based on their existing expertise.
>
> Uma and Rakesh already started to contribute to Ozone, and their
> expertise and enthusiasm already proven as Hadoop PMC members. They
> are
> suggested more members to include as they can help significant Ozone
> to
> be successful.
>
> Junping helped a lot with designs feedback and to get the first
> enterprise adoption of Ozone for production.
>
> Sammi was so kind to accept the nomination to be the initial Chair of
> the project from the side of an “adopter/user” company.  (Hadoop bylaw
> suggest rotating this role, if we keep the same bylaw we can rotate it
> later between different community members).
>
> The initial version of this list (With existing Apache id, Apache
> membership and Hadoop project membership information) can be found on
> the proposal page:
>
>
> https://cwiki.apache.org/confluence/display/HADOOP/Ozone+Hadoop+subproject+to+Apache+TLP+proposal
>
> As any other list it’s not perfect. It can be extended, but in this
> phase it’s harder to get a full consensus (no Ozone specific private
> list or place for private conversation). I hope we can add more people
> after creating the new Ozone project.
>
> (NOTE: as usual, the proposed members can reject this opportunity, we
> need to ping everybody on the list)
>
> IMPORTANT1: if you have any more suggestions, opinion please share it.
>
> (if you prefer to do so, you can do it in private, you can send it to
> me
> or any proposed PMC members, and the information will be shared
> between
> the proposed PMC members).
>
> IMPORTANT2: Based on the previous example of Submarine, and the
> request
> of the Hadoop community any Hadoop committers can request opt-in
> committer role and can have automatic membership (except somebody from
> the initial PMC list has a strong veto).
>
>
> Thanks,
> Marton
>
> -
> To unsubscribe, e-mail: ozone-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: ozone-dev-h...@hadoop.apache.org
>
>
> -
> To unsubscribe, e-mail: ozone-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: ozone-dev-h...@hadoop.apache.org
>
>

Re: Ozone 0.6.0 release preparation (1.0.0?)

[Jitendra Pandey]

+1 to change the version to 1.0.0

On Wed, Aug 12, 2020 at 7:31 AM Sammi Chen  wrote:

> We have resolved all JIRAs targeting 0.6.0 by today.  Thanks everyone for
> your continuous contribution!
>
> All 0.6.0 commits are cherry-picked from master to ozone-0.6.0, except this
> revert request(https://github.com/apache/hadoop-ozone/pull/1313) which is
> pending for confirmation.
>
> I will start to build the first RC package tomorrow.
>
> As for the proposal to change the version from 0.6.0 to 1.0.0,  do we need
> 3 "+1" to proceed?
>
> Thanks,
> Sammi
>
> On Tue, Jul 28, 2020 at 3:27 AM Dinesh Chitlangia 
> wrote:
>
> > +1 for 1.0.0 as GA
> >
> > On Thu, Jul 23, 2020 at 8:32 AM Sammi Chen  wrote:
> >
> > > Marton,  good idea. 1.0.0 is a good candidate for GA version.
> > >
> > > I will wait a few days in case there is other feedback.
> > >
> > > Sammi
> > >
> > > On Mon, Jul 20, 2020 at 6:03 PM Elek, Marton  wrote:
> > >
> > > >
> > > > On 7/10/20 11:50 AM, Mukul Kumar Singh wrote:
> > > > > +1 for GA as well.
> > > > >
> > > > > We have done lots of compatibility testing with Ozone with Hive and
> > > > Spark. >
> > > >
> > > > I have the same question as on the Ratis side.
> > > >
> > > > If we think it's GA, why don't we call it 1.0.0 ?
> > > >
> > > >
> > > > Marton
> > > >
> > > > -
> > > > To unsubscribe, e-mail: ozone-dev-unsubscr...@hadoop.apache.org
> > > > For additional commands, e-mail: ozone-dev-h...@hadoop.apache.org
> > > >
> > > >
> > >
> >
>

Re: Ozone 0.6.0 release preparation

[Jitendra Pandey]

+1 to call it GA.
Agree with Arpit that we will need to provide compatibility and upgrade
paths, going forward.

On Wed, Jul 8, 2020 at 9:48 AM Arpit Agarwal 
wrote:

> Quality aside, declaring GA means:
> 1. We will not make incompatible changes to wire protocols, APIs, tools or
> on-disk formats.
> 2. We will support upgrades from GA to any future release.
>
> I am +1 to call this a GA release, assuming Sammi approves as the RM.
>
> On Wed, Jul 8, 2020 at 6:12 AM Sammi Chen  wrote:
>
> > Branch ozone-0.6.0 is created today.
> >
> > So far we have 18 opens for 0.6.0.  You can find the details from
> >
> >
> >
> https://issues.apache.org/jira/issues/?jql=project+%3D+HDDS+AND+cf%5B12310320%5D+%3D+0.6.0+AND+status+in+%28Open%2C+%22In+Progress%22%2C+Reopened%2C+%22Patch+Available%22%29
> >
> >
> > Our internal cluster is upgraded recently using master branch, and has a
> > lot of new issues after that, like HDDS-3921, HDDS-3920, HDDS-3892,
> > HDDS-3933.  Now most of the issues are root caused and will be fixed
> soon.
> >
> >
> > @Bharat Viswanadham，
> >
> > I'm open for the question.
> >
> >
> > Thanks,
> >
> > Sammi
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Jul 8, 2020 at 9:38 AM Bharat Viswanadham
> >  wrote:
> >
> > > Hi,
> > > Are we planning to make the next version of the Ozone release as GA?
> > >
> > > *Few points to consider in making ozone GA release.*
> > > 1. A lot of testing has been done with Hive and Spark TPC-DS.
> > > 2. Scale test is also done. A billion object test is also run on Ozone.
> > >
> > >
> > > Thanks,
> > > Bharat
> > >
> > >
> > >
> > > On Sun, Jun 21, 2020 at 8:56 PM Sammi Chen 
> wrote:
> > >
> > > > Hi, everyone,
> > > >
> > > > Here is the planned feature list of 0.6.0 release.
> > > >
> > > >- Security Phase II
> > > >- HA support for Ozone Manager
> > > >- OFS (HDDS-2665), new scheme:  ofs://om/volume/bucket/key
> > > >- Ozone Filesystem performance improvement (HDDS-2939)
> > > >- Ozone support security enabled Hadoop 2.x
> > > >- S3 volume/bucket mapping changes and bind mounted buckets
> > > (HDDS-3385)
> > > >- Hadoop 2.7 support / remove of Isolated class loader (HDDS-3458)
> > > >- Recon / Recon UI improvements (new management / debug screens)
> > > >https://cwiki.apache.org/confluence/display/HADOOP/Ozone+Road+Map
> > > >
> > > > Based on current feature implementation status, I'd like to propose
> to
> > > move
> > > > "HDDS-2939 Ozone FileSystem performance improvement" to the next
> 0.7.0
> > > > release.
> > > >
> > > > Currently, there are 173 open JIRAs targeting 0.6.0.  Here is the
> list,
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project+%3D+HDDS+AND+cf%5B12310320%5D+%3D+0.6.0+AND+status+in+%28Open%2C+%22In+Progress%22%2C+Reopened%2C+%22Patch+Available%22%29
> > > >
> > > > Let me know if some important JIRAs are missing from the above list.
> > > > I plan to have the ozone-0.6.0 branch cut by the end of this week and
> > > > create the first RC early next week.
> > > > Welcome any feedback.
> > > >
> > > >
> > > > Bests,
> > > > Sammi
> > > >
> > >
> >
>

Re: [DISCUSSION] Making OFS the default, deprecating o3fs

[Jitendra Pandey]

I think we should not be deprecating o3fs. It is ok to make 'ofs' default.
o3fs couldn't be a default anyway because it needs a bucket created.
However, let's not rush to delete o3fs.
We can have both ofs and o3fs around, they have their own respective
advantages. A few releases down the line, we may have more data on which
file system sees more adoption.
For example, consider multi-tenant use cases where a customer wants
isolated namespaces for two different business units. For a hybrid cloud
deployments, where a user wants to migrate data between ozone buckets and
s3 buckets, o3fs may turn out to be more conducive, given the file system
is rooted in an ozone bucket, similar to a s3 bucket in the cloud.
That said, I am +1 to following:
  - Offer 'ofs' as the default file system.
  - Update documents to reflect ofs, but keep a section for o3fs as well
for folks who have tried o3fs in the past and want to continue using it.
  - Add ofs tests, but keep o3fs tests around so that it doesn't regress.
  - Evangelize 'ofs' as the primary file system offering, as it is easier
to use.

On Wed, Jun 24, 2020 at 8:50 AM Wei-Chiu Chuang
 wrote:

> Sounds good to me as long as we make sure all user docs are updated to use
> o3fs as examples.
>
> On Tue, Jun 23, 2020 at 11:35 AM Siyao Meng 
> wrote:
>
> > Fellow Ozone developers,
> >
> >   I am thinking of making OFS the default since it should be the way
> > forward. The main reason I am sending this email is that I am about to do
> > some work to deprecate o3fs and replace existing o3fs paths in the
> existing
> > user guides with OFS ones. Also, new tests will be added to test OFS
> (e.g.
> > MapReduce acceptance tests). OFS follow-up work uber jira is created
> > at HDDS-3820.
> >
> >   At least for the upcoming 0.6.0 release, both o3fs and OFS will be
> usable
> > on the client. o3fs won't be gone any time soon.
> >
> >   If you have any concerns, comments and suggestions. Feel free to
> discuss
> > it in this thread. Thanks!
> >
> > Cheers,
> > Siyao Meng
> >
>

Re: [RESULTS] Community sync survey results

[Jitendra Pandey]

> Currently there is a meeting on Friday 12:15PM Beijing / 9:45AM India,
> Thursday  9:15 PM PST between Tencent and Cloudera

+1 to merge the community meeting with this one, as suggested by Sammi.

On Thu, Jun 4, 2020 at 7:58 PM Sammi Chen  wrote:

> Hi Marton,
>
> Thanks for initiate the survery and collect the result.
>
> Currently there is a meeting on Friday 12:15PM Beijing / 9:45AM India,
> Thursday  9:15 PM PST between Tencent and Cloudera.  If the community is
> going to start a new sync meeting at the second half of the week,   I'd
> like to propose to merge these two meetings into one.
>
> @Xiaoyu Yao   @Mukul Kumar Singh
>Would like to hear your thoughts on this.
>
> Thanks,
> Sammi
>
>
> On Thu, Jun 4, 2020 at 6:45 PM Elek, Marton  wrote:
>
> >
> > A few weeks ago we started a new Survey to make our Community Sync more
> > inclusive (for more time zones).
> >
> > Thank you for all the answers (22), I think it helps a lot to make our
> > Sync more effective and more inclusive.
> >
> > The raw results are available from here:
> >
> > https://home.apache.org/~elek/ozone-survey-results.csv
> >
> > But in this mail I will give a quick summary with the possible action
> > items.
> >
> >
> >
> >
> >
> > 1. QUESTION: Do you read the meeting minutes from the ozone-dev mailing
> > list? Do they help for you?
> >
> > ANSWERS:
> >
> > The answer was a strong yes. (82%).
> >
> > ACTION ITEMS:
> >
> > We should continue to write meeting minutes and publish it on the
> > mailing list.
> >
> > As I am not always available (Summer is coming) I will ask volunteers to
> > write it when I can't do it.
> >
> > Based on the suggestion below, I will start to archive the minutes on
> > the wiki (as Anu did). But I prefer to include the full text in the
> > mailing lists too (as it's also archived, with different method.
> >
> > NOTABLE COMMENTS:
> >
> >   * Maybe we should notify the meeting though multi-way, mail-list,
> > slack, wechat, and any other way.
> >
> >   * It would be really great if you could summarize weekly meeting notes
> > in wiki like
> >
> https://cwiki.apache.org/confluence/display/HADOOP/2020-01-07+Meeting+notes
> > .
> >
> >
> >
> >
> >
> > 2. QUESTION: Do you prefer recordings of the meetings?
> >
> > ANSWERS:
> >
> > 38 % : yes
> > 33 % : yes, with limited retention
> >
> > ACTION ITEMS:
> >
> > As it's 71 % for recording, I think we should start to record it, share
> > it, but we can delete the recordings after 1 month
> >
> >
> >
> >
> >
> > 3. QUESTION: What is your preferred scheduling scheme?
> >
> > ANSWERS:
> >
> > 41 %: One call a week, same time
> > 36 %: One call a week / alternating times
> >
> > ACTION ITEMS:
> >
> > Here, I don't know what should we do. Both can work, but we agreed that
> > the existing one should be kept. There is no good decision here as far
> > as I see.
> >
> > I will propose to start a new meeting at EMEA/APAC friendly time which
> > can work for PST (PST late night but before midnight).
> >
> > We will see how does it work and can transform some of the events to
> > more specific design discussion.
> >
> >
> > NOTABLE COMMENTS:
> >
> > * its better to talk English slowly and clearly, for some body don't
> > good at the English with accent. Its better to have translator.
> >
> >
> >
> >
> >
> > 4. QUESTIONS What is your preferred workday for the call
> >
> > ANSWERS: beginning of the week is better (Monday 72% ---> Friday 18%)
> >
> >
> > 5. QUESTION: Which time is best for you (in your local time, defined in
> > the previous question)
> >
> >
> > ANSWERS:
> >
> > I analyzed it with google spreadsheet, but but time slots are the
> > following:
> >
> > A) existing slot
> >
> > GMT/Belfast: 16
> > Budapest (summer): 18
> > Beijing: 24
> > New York (summer): 12
> > Seattle/California (summer): 9
> > India: 21:30
> >
> > feedback categories:
> >
> > Good + Acceptable: 11 (8 + 3)
> > Impossible: 7
> >
> > B) additional slot
> >
> > GMT/Belfast: 8:30
> > Budapest (summer): 6:30
> > Beijing: 12:30
> > New York (summer): 0:30
> > Seattle/California (summer): 21:30
> > India: 10:00
> >
> >
> > Good + Acceptable: 12 (9 + 3)
> > Impossible: 6
> >
> > (Note, It's a 2-2:30 hours slot the time can be moved, but later is
> > harder for Europe (6 am), later is harder for Pacific (22 = 10pm)
> >
> >
> > ACTION ITEM:
> >
> > I propose to start a new Sync at 8:30 am GMT. Based on the vote,
> > Wednesday seems to be a good choice, but as far as I know there is an
> > unofficial sync between a few contributors at Friday which also can be
> > moved later.
> >
> > I think we can start it weekly (harder to switch to alternating times
> > IMHO) but with more focused:
> >
> >   * having an agenda in advance!
> >   * With agenda we can spend more time on design discussions
> >
> >
> >
> >
> >
> >
> > 6. ADDITIONAL FEEDBACK:
> >
> >
> >   * A way to propose topics ahead of time, or to sign up for a time slot
> > to ask for inputs on a topic
> >
> >   * As we have only hundred 

Re: [design] S3 access key management

[Jitendra Pandey]

Thanks for starting this thread Marton. We need to address this for better
usability.
 How do I comment on the document? Do I need Hackmd account?

On Fri, Feb 28, 2020 at 5:47 AM Elek, Marton  wrote:

>
> Hi,
>
> We had multiple discussions earlier about simplifying s3_bucket ->
> ozone_volume/ozone_bucket mapping (or at least make it more opaque)
>
> I wrote a formal proposal about a very lightweight change:
>
> https://hackmd.io/uqSYkmd8SXGAAjQx3sObQg?view
>
> Please let me know what do you think...
>
>
> Thanks a lot,
> Marton
>
> -
> To unsubscribe, e-mail: ozone-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: ozone-dev-h...@hadoop.apache.org
>
>

Re: [Discuss] Ozone moving to Beta tag

[Jitendra Pandey]

+1. Given massive improvements in performance and stability, ozone is ready
for beta.

On Wed, Feb 19, 2020 at 1:04 PM Salvatore LaMendola (BLOOMBERG/ 919 3RD A) <
slamendo...@bloomberg.net> wrote:

> +1 on moving to beta. This move makes sense to me.
>
> I've tested each point release so far in 0.4, including building several
> master snapshots along the way, and I agree with what Anu is saying below
> with regard to Ozone's stability having improved beyond "alpha" state.
>
>
> From: aengin...@apache.org At: 02/19/20 15:17:38To:
> ozone-dev@hadoop.apache.org,  hdfs-...@hadoop.apache.org
> Subject: [Discuss] Ozone moving to Beta tag
>
> Hi All,
>
>
> I would like to propose moving Ozone from 'Alpha' tags to 'Beta' tags when
> we do future releases. Here are a couple of reasons why I think we should
> make this move.
>
>
>1. Ozone Manager or the Namenode for Ozone scales to more than 1 billion
>keys. We tested this in our labs in an organic fashion; that is, we were
>able to create more than 1 billion keys from external clients with no
> loss
>in performance.
>2. The ozone Manager meets the performance and resource constraints that
>we set out to achieve. We were able to sustain the same throughput at
> Ozone
>manager for over three days that took us to get this 1 billion keys.
> That
>is, we did not have to shut down or resize memory for the namenode as we
>went through this exercise.
>3.  The most critical, we did this experiment with 64GB of memory
>allocation in JVM and 64 GB of RAM off-heap allocation. That is, the
> Ozone
>Manager was able to achieve this scale with far less memory footprint
> than
>HDFS.
>4. Ozone's performance is at par with HDFS when running workloads like
>Hive (
>
>
> https://blog.cloudera.com/benchmarking-ozone-clouderas-next-generation-storage-f
> or-cdp/
> 
>)
>5. We have been able to run long-running clusters with Ozone.
>
>
> Having achieved these goals, I propose that we move from the planned
> 0.4.2-Alpha release to 0.5.0-Beta as our next release. If we hear no
> concerns about this, we would like to move Ozone from Alpha to Beta
> releases.
>
>
> Thanks
>
> Anu
>
>
> P.S. I am CC-ing HDFS dev since many people who are interested in Ozone
> still have not subscribed to Ozone dev lists. My apologies if it feels like
> spam, I promise that over time we will become less noisy in the HDFS
> channel.
>
>
> PPS. I know lots of you will want to know more specifics; Our blog presses
> are working overtime and I promise you that you will get to see all the
> details pretty soon.
>
>
>

Re: [VOTE] Apache Hadoop Ozone MultiRaft Support

[Jitendra Pandey]

+1 (binding) for the merge

On Mon, Feb 10, 2020 at 6:19 PM Siddharth Wagle 
wrote:

> +1 for the merge. Thank you for contributing this important feature.
>
> Best Regards,
> Sid
>
> On Mon, Feb 10, 2020 at 10:25 AM Xiaoyu Yao 
> wrote:
>
> > +1 (Binding). Thanks all for getting this feature complete.
> >
> > Regards,
> > Xiaoyu
> >
> > On Mon, Feb 10, 2020 at 10:15 AM Anu Engineer 
> > wrote:
> >
> > > +1(Binding), Very excited for this feature.  Thanks for getting this
> > done.
> > >
> > > Thanks
> > > Anu
> > >
> > >
> > > On Mon, Feb 10, 2020 at 12:08 AM timmycheng(程力) <
> timmych...@tencent.com>
> > > wrote:
> > >
> > > > Hey all,
> > > >
> > > > The support for multi-raft feature for ozone has been put together
> in:
> > > > https://issues.apache.org/jira/browse/HDDS-1564.
> > > >
> > > > Pull request for changes:
> > > > https://github.com/apache/hadoop-ozone/pull/538
> > > >
> > > > Test brief and design, see attachments in:
> > > > https://issues.apache.org/jira/browse/HDDS-1564
> > > >
> > > > Previous discussion thread:
> > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/hadoop-ozone-dev/202002.mbox/browser
> > > >
> > > > Feedbacks and comments so far:
> > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/1NxCiHhn0u9BqgjuUXB8zxGtny69Qek4yTFe1QqUHiqM/edit
> > > >
> > > > This release contains 18 commits. Shout out to those who have inputs
> as
> > > > well as help to review.
> > > > Please reply with feedbacks and comments and thanks in advance.
> > > >
> > > > *The vote will run for 7 days, ending on Feb 17th 2019 at 11:59 pm
> > PST.*
> > > >
> > > >
> > > > -Li
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Ozone 0.4.2 release

[Jitendra Pandey]

+1


> On Dec 7, 2019, at 9:13 AM, Arpit Agarwal  
> wrote:
> 
> +1
> 
> 
> 
>> On Dec 6, 2019, at 5:25 PM, Dinesh Chitlangia  wrote:
>> 
>> All,
>> Since the Apache Hadoop Ozone 0.4.1 release, we have had significant
>> bug fixes towards performance & stability.
>> 
>> With that in mind, 0.4.2 release would be good to consolidate all those 
>> fixes.
>> 
>> Pls share your thoughts.
>> 
>> 
>> Thanks,
>> Dinesh Chitlangia
> 
> 
> -
> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: common-dev-h...@hadoop.apache.org
> 

-
To unsubscribe, e-mail: ozone-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: ozone-dev-h...@hadoop.apache.org