Thanks Shashikant for starting the discussion.
Marton has recently proposed a solid checklist to go through before
branch merge:
https://cwiki.apache.org/confluence/display/OZONE/Merging+branches
One of the items is basic documentation as suggested by Xiaoyu.
It would be great if we could get a c
On Thu, Mar 25, 2021 at 7:32 AM Elek, Marton wrote:
> My proposal is:
>
> 1. Restore the master to the previous state.
> 2. Invalidate/revoke the leaked secret ASAP
> 3. Revert the problematic commit and recommit it without the problems
> 4. (IN the future) do discussions which includes al
Hi Prashant,
> You can find the RC1 artifacts at:
> https://home.apache.org/~prashantpogde/ozone-1.1.0-rc1/
Thanks for preparing RC1.
Signatures are OK for both src and bin tarball.
I found the following problems:
* Build from source fails due to missing dev-support/byteman
directory, which th
> https://home.apache.org/~prashantpogde/ozone-1.1.0-rc2/
Thanks Prashant for updating to RC2.
+1
* Verified signatures, checksums
* Verified source matches ozone-1.1.0-RC2 tag
* Verified `ozone version` (version number, git revision)
* Built from source without local Maven cache
* Executed upgr
Thanks Marton for sharing your thoughts.
> which commit is the merge candidate?
I think this is an important question. The merge vote should be about
a specific commit, similar to releases. It's a moving target either
way (one's evaluation might be obsolete by the next commit), but at
least it
Hi Ethan,
Thanks for creating RC0.
Signatures are OK for both src and bin tarball.
Docs are missing from the binary archive. Hugo is required for
building the docs.
-Attila
On Mon, Nov 1, 2021 at 6:44 PM Ethan Rose wrote:
>
> Hello all,
>
> As discussed earlier, I am calling for a vote on Ap
Thanks Ethan for creating a new RC. Looks mostly good to me:
* Verified signatures, checksums
* Verified source matches ozone-1.2.0-RC1 tag
* Verified docs are present in binary tarball
* Verified `ozone version` (version number, git revision)
* Built from source without local Maven cache
* Execu
+1
* Verified signatures, checksums
* Verified source matches ozone-1.2.0-RC2 tag
* Verified docs are present in binary tarball
* Verified `ozone version` (version number, git revision, repo URL)
* Built from source without local Maven cache
* Executed upgrade acceptance test with both source and
Thanks to everyone who contributed to this feature.
Neil created a draft PR where the code change for this feature branch
can be reviewed: https://github.com/apache/ozone/pull/3297
I posted some questions/comments there.
> *The vote will run for 7 days, ending on Apr 12 at 8:00 PT.*
I'd like to
> 1. We should ensure that information is never removed from command output,
> unless it is deprecated and removed gracefully after some number of
> releases. For JSON the existing field names and location in the JSON
> structure should remain the same.
>
> 2. Information can be added to command ou
+1 for the branch merge.
There is one item left in the PR (TestOzoneConfigurationFields applied
to S3 config).
Neil, can you please open a Jira issue for each of the items addressed
in the draft PR (excluding merges from master) since it was opened?
Those changes would need to be brought into the
Thanks Pifta for starting the discussion.
I think we can sum up your comparison of feature branch vs. master
development as: the problems we usually have to solve with feature
branches are procedural (busywork), while solutions required for a
comparable master-based model improve the product itsel
Thanks MingChao for creating rc1.
+1
* Verified signatures, checksums
* Verified docs in binary tarball
* Verified `ozone version`
* Built from source
* Ran upgrade acceptance tests
I've noticed there are some extra files in the source tarball,
probably leftover from build of binary one:
Only i
+1
-Attila
-
To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org
For additional commands, e-mail: dev-h...@ozone.apache.org
Hi Nanda,
> Currently, we compile and verify Ozone only with Java 8. As far as I know,
> we haven't tested Ozone either with Java 11 or 17.
CI compiles each commit with both Java 8:
https://github.com/apache/ozone/blob/d6f63bf2e53ac8a4220ee829d8bbb2427dd7d3fa/.github/workflows/ci.yml#L60-L68
http
+1
* Verified signatures, checksums
* Verified docs in binary tarball
* Verified `ozone version`
* Built from source
* Ran upgrade acceptance tests
-Attila
-
To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org
For additiona
Hi Prashant,
> We will go ahead and merge the Snapshot branch into master.
There is a new integration test that has been failing consistently
since it was introduced on the feature branch (last 3 commits and a
new PR). Please only merge to master after it is fixed.
https://issues.apache.org/jir
Hi committers and future committers,
Please be careful when merging PRs. Github's default behavior [1] of
composing the commit message may not be the best for our purposes.
1. If the PR has a single commit, Github defaults to using the
commit's message instead of the PR title. Jira ID might be
Thanks Wei-Chiu for the report, I've created HDDS-8955 for this.
> btw. which test?
Robot-based acceptance tests for HttpFS [1] run in Docker [2].
-Attila
[1]
https://github.com/apache/ozone/tree/1356b93aa6c73f92f049353bb1d53b9438f34e4b/hadoop-ozone/dist/src/main/smoketest/httpfs
[2]
https://
Hi all,
> Thanx Wei-Chiu for the initiative. Definitely makes sense to move to
> 2.10.x line instead of 2.7, if anyone in the Hadoop ecosystem wants to
> stay over in 2.x line, it shouldn't be that tough for them to move to
> 2.10.x from 2.7
>
> +1 to drop Hadoop-3.2, I have heard very few people
> The default message uses the commit title and message if the pull request
> contains only 1 commit, or the pull request title and list of commits if
> the pull request contains 2 or more commits. You can also choose to use
> just the pull request title, the pull request title and commit details,
Hi Sammi,
> As for the co-author, what about manually adding it to the title? like this
> "Contributed" message
>
> *HDFS-17086. Fix the parameter settings in
> TestDiskspaceQuotaUpdate#updateCountForQuota (#5842). Contributed by
> Haiyang Hu.*
In your example "Contributed by" indicates the singl
Hi Yiyang and devs,
In today's US community sync two other bugs targeted at 1.4.0 were
marked as blocker:
* HDDS-9709. Intermittent NO_REPLICA_FOUND due to OM pipeline cache bug
* HDDS-9762. Hadoop s3a protocol does not work with FSO buckets
The first one should be quick: it already has a patch
Thanks Yiyang for creating RC0.
On Mon, Jan 8, 2024 at 9:15 AM wanghongbing <284734...@qq.com.invalid> wrote:
> When extracting the ozone-1.4.0.tar.gz from the URL
> https://dist.apache.org/repos/dist/dev/ozone/1.4.0-rc0/ using the `tar zxf
> ozone-1.4.0.tar.gz` command, the following log is en
+1
* Verified signatures, checksums
* Verified source matches ozone-1.4.0-RC1 tag
* Verified docs in binary tarball
* Verified `ozone version`
* Built from source
* Ran upgrade acceptance tests
Thanks Yiyang for creating RC1.
-Attila
-
Hi Hemant,
> Jira priority is not set properly. If it helps I can change it to blocker
> for 1.4.0 release.
1.4.0 is released (vote passed, artifacts in place), it's just not
announced yet on the website.
> Both issues are important for Ozone Snapshot feature and if the issue
> occurs, we have t
Thanks Yiyang for driving the release to completion.
-Attila
-
To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org
For additional commands, e-mail: dev-h...@ozone.apache.org
Hi Ozone developers,
I would like to propose preparing the next release based on master
instead of the ozone-1.4 branch.
Unlike with previous releases, we started regularly backporting fixes
to ozone-1.4 soon after Ozone 1.4.0 was released. Currently 99
commits are present on the branch on top o
Hi Ozone developers,
I would like to propose merging into master the feature branch
HDDS-10656-atomic-key-overwrite, which was used to develop Atomic Key
Overwrite.
There are scenarios where it would be desirable to replace a key in
Ozone, but only if the key has not changed since it was read. T
> I would like to propose merging into master the feature branch
> HDDS-10656-atomic-key-overwrite, which was used to develop Atomic Key
> Overwrite.
Thanks for the votes so far. Would anyone else like to vote?
-Attila
-
To uns
> I would like to propose merging into master the feature branch
> HDDS-10656-atomic-key-overwrite, which was used to develop Atomic Key
> Overwrite.
Vote passed after 2 weeks with 3 binding +1s (Ayush, Stephen, Tsz-Wo),
6 other +1s, no other votes.
Thanks everyone for voting.
-Attila
-
> > Both issues can be addressed with new layout versions. I will open JIRA
> > tickets to include these fixes in the next release, version 1.5.0.
>
> Thanks Wei-Chiu, I'm ok with handling these in follow up tasks. Please
> share the Jira links when you have them. This was my main concern, so the
>
Hi Ozone developers,
Work on a Helm chart for Ozone was recently started by contributor
Denis Krivenko, an Apache Kyuubi committer. Its code is hosted at
https://github.com/apache/ozone-helm-charts
Apache projects seem to follow two different approaches to releasing
Helm charts:
A) Automated: u
> It looks to me these protocol versions and layout versions concerns can be
> addressed quickly. I took a stab at it and posted them in three separate
> PRs.
Thanks Wei-Chiu for addressing compatibility concerns, I'm OK with
merging the feature branch.
-Attila
--
Thanks Xi Chen for working on the release.
Can we also include HDDS-11040?
-Attila
-
To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org
For additional commands, e-mail: dev-h...@ozone.apache.org
> https://github.com/apache/ozone/releases/tag/ozone-1.4.1-RC1
> https://dist.apache.org/repos/dist/dev/ozone/1.4.1-rc1/
+1
* Verified signatures, checksums
* Verified source matches ozone-1.4.1-RC1 tag
* Verified docs in binary tarball
* Verified `ozone version`
* Built from source
* Ran upgrade
> Do we test against Hadoop S3A client?
We run S3A contract tests from Hadoop using Ozone (running in
docker-compose) as S3 endpoint. Some tests are skipped due to known
issues.
https://github.com/apache/ozone/blob/789fb53f9e07e636134b0bace8a2876dcaa85f09/hadoop-ozone/dist/src/main/compose/commo
Hi Ozone users and developers,
I am pleased to announce the release of the initial version of Helm
Chart for Apache Ozone [1]. I would like to thank Denis Krivenko for
the contribution of both the chart definition and the CI workflows.
Feedback is welcome.
-Attila
[1] https://github.com/apache
> I'm ok with either having this in the SECURITY.md file or tracking this in
> the Ozone website. (We can even do both)
- The list of releases supported is going to change in time, but
release artifacts are immutable. How do we invalidate the list
included in an old release?
- Multiple release li
> > +1 for moving supported version list to the website and out of the release
> > artifact. As Attila said, this is a living document so it does not really
> > fit into immutable releases. We can find a place for it in the old and new
> > website, but my first guess would be to put it on the downl
> Apache projects seem to follow two different approaches to releasing
> Helm charts:
>
> A) Automated: using GitHub Actions, publish chart index via GitHub
> Pages, host artifacts on GitHub
>
> B) Manual: prepare RC, vote, etc., publish chart index to project
> website, host artifacts on downloads
> Could it be that only Recon requires Java 21?
Yes, technically only Recon (its dependencies) as far as I know. But:
- I think it's easier to manage hosts with uniform Java version
- we don't know when some other dependency of OM/SCM/etc. starts
requiring newer Java
So for these reasons I thin
Thanks Ayush, Tsz-Wo, for finding these problems.
> I think it should be OK to use this RC.
I agree. The issues are minor and not new to 1.4.1.
-Attila
-
To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org
For additional
Hi Apache Ozone community,
Ozone currently requires minimum Java 8 at both build and run time,
but it compiles and runs fine with newer Java versions. The GitHub CI
workflow includes compilation with Java 11, 17 and 21. Tests are run
with Java 17.
Java 21 has been GA for more than a year, Java 1
> I am calling for a vote on Apache Ozone 1.4.1 RC3.
> https://github.com/apache/ozone/releases/tag/ozone-1.4.1-RC3
> https://dist.apache.org/repos/dist/dev/ozone/1.4.1-rc3/
+1
* Verified signatures, checksums
* Verified source matches ozone-1.4.1-RC3 tag
* Verified docs in binary tarball
* Verif
Hi Ozone developers,
Ivan Zlenko has started working on standardizing license header and
the order of imports.
The first PR [1] adds the sample header [2], as well as checkstyle
rules for these two items. Rules will be initially disabled in all
submodules. The plan is to update submodules gradu
Hi Wei-Chiu, Abishek,
We had this process [1] for a few years now that design docs should be
created as markdown in hadoop-hdds/docs/content/design via pull
request (some examples at [2]). Rendered versions are available on
the website [3].
[1] https://ozone.apache.org/docs/edge/design/ozone-enh
Thanks Wei-Chiu for working on the release.
> Source code and binary tarball:
> https://dist.apache.org/repos/dist/release/ozone/2.0.0-rc0/
RC should be added in dist/dev, not dist/release.
> I built on a Mac M3. Does it make any difference if I build on an x86 Linux?
On Linux, the binary tarba
> I'm not sure which KEYS file is the correct one -- the one under /release/
> or the one under /dev/?
release is the correct one. dev is for the case if "you are a
committer and not a PMC member".
-Attila
-
To unsubscribe, e-m
Thanks Wei-Chiu for RC2.
> Git tag: https://github.com/apache/ozone/releases/tag/ozone-2.0.0-RC2
> https://dist.apache.org/repos/dist/dev/ozone/2.0.0-rc2/
> https://repository.apache.org/content/repositories/orgapacheozone-1031/
+1
* Verified signatures, checksums
* Verified source matches ozone
-- Forwarded message -
The Travel Assistance Committee (TAC) are pleased to announce that
travel assistance applications for Community over Code Asia 2025 are now
open!
We will be supporting Community over Code Asia, Beijing, China
July 25th to the 27th 2025.
TAC exists to help
> (the remaining tasks of HDDS-11754 don't look like must-do's)
I think HDDS-12327 needs to be investigated. Finding upgrade problems
after the release would be less than ideal.
-Attila
-
To unsubscribe, e-mail: dev-unsubscr...
> Can we comment the failed S3 Recon test for now to make CI green if this is
> the only test failing. Because locally it is passing. We can check it once CI
> is green.
No need to disable tests.
Root cause:
https://github.com/actions/runner-images/issues/12178
Workaround:
https://github.com/a
> Hi it looks like a few recon tests are not stable today.
It's not only Recon, few other tests too:
org.apache.hadoop.ozone.TestSecureOzoneCluster
org.apache.hadoop.ozone.s3.awssdk.v1.TestS3SDKV1
org.apache.hadoop.ozone.s3.awssdk.v1.TestS3SDKV1WithRatisStreaming
org.apache.hadoop.ozone.s3.awssdk
Workaround is merged, thanks Zita for the review.
Please note: simply re-running failed checks is not enough, merge
master into your branch.
-Attila
-
To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org
For additional comma
> My primary goal is to push for a more regular and predictable
> release schedule, as I believe this would accelerate the delivery of
> features more effectively.
+1, I also think that regular releases would be better.
But then we shouldn't discuss features to be included, rather release
schedul
> We can file an INFRA ticket to require a description field when filing a
> jira issue. If no one objects I can open an INFRA jira.
+1 for mandatory description.
> I'd actually want to go one step further and to have a pre-filled template
-1 for pre-filled template. It defeats the purpose of m
57 matches
Mail list logo
