Hi Stephen,
Thanks for starting this thread.
I am +1. I agree that adding new lines should be allowed.
It's hard to provide a flag for every addition as that can bring many flags
and make things ungly eventually.
Nilotpal, if you have some tests around validating the command
line outputs, would
Thanks for the comments Nilotpal,
I have created a Jira to track commands with missing JSON output, and added
one Jira to it already:
https://issues.apache.org/jira/browse/HDDS-6637
If you, or anyone, comes across a command that is missing the JSON option,
please add a Jira to that epic and we e
Also a reminder that there is still a merge vote for HDDS-4440 ongoing as
well. It may be best to resolve that before discussing a release.
On Fri, Apr 22, 2022 at 7:32 AM Ethan Rose wrote:
> Hi MingChao, thanks for driving this effort.
>
> We have a few release blockers on the upgrade side that
Hi MingChao, thanks for driving this effort.
We have a few release blockers on the upgrade side that need to be resolved
before we can release:
- SCM HA finalization (I have begun working on this): HDDS-5141
- Onboarding FSO into the upgrade framework (this can start now that EC has
been onboarded
I think we could mark EC as a [tech preview] feature clearly in this 1.3.0
release.
And we could release EC as a completed feature in the next release if possible.
At 2022-04-22 20:26:07, "Kota Uenishi" wrote:
>I would welcome 1.3 release even without EC available. This is because
>a
I would welcome 1.3 release even without EC available. This is because
a lot of other features and fixes I need in our system. For example,
HDDS-5881, HDDS-5461, HDDS-5656, HDDS-5975, HDDS-6321 and such.
Delivering them would be very valuable.
As RocksDB crash is also happening in our cluster inter
Hi Stephen ,
I am +1 on having both human readable output and json output (with an extra
argument) for CLI commands.
Please make sure, for ALL the CLI commands/sub-commands , json outputs are
present before actually making changes in human readable CLI outputs.
Otherwise, tests would still rely
I think 1.2.2 sounds like a bug fix version.If we are going to release a new
feature version, 1.3.0 would be the proper name. On 星期五, 22 四月 2022
19:13:18 +0800 captain...@apache.org wrote Thanks @Stephen for your
feedback.
Maybe we can de-emphasize the EC in this version. If EC recov
Thanks @Stephen for your feedback.
Maybe we can de-emphasize the EC in this version. If EC recovery is
completed, it will take until the second half of the year.
It's been a little long since the last release. Since last release, FSO,
S3gateway, OM, container Balancer have made some
optimizations
My feeling is that it may be worth waiting until the recovery side of EC is
working before releasing. As it stands, EC is not in a usable form - the
feature is half done. If we release 1.3.0 now, we cannot state EC is
available in it.
On Fri, Apr 22, 2022 at 9:43 AM mingchao zhao wrote:
> Dear a
Thanks @Symious for your feedback.
Every time we release a new version, in addition to releasing new features,
it is more important to fix some bugs from the previous version.
In 1.2 we released new features (SCM HA, FSO, Non rolling upgrades) and we
also fixed some bugs this time. This also in or
Thanks @MingChao for bringing this up.
Looking forward to the release with these new great features.
But IMHO, since these are quite large changes of the new features, and some
indetectable bugs may need some time and usage to show themselves.
In order to provide a more stable release for all us
Dear all,
It has been a few months since the Ozone 1.2.0 & 1.2.1 release, and we have
had a
number of new features (EC）and some optimization(s3gateway) and some
bug fixes
for 1.2 that have been merged to master since then. I think this would be a
good time
to work on the Ozone 1.3.0 release. Also,
13 matches
Mail list logo
