Re: [DISCUSS] Feature branch vs Master based dev

I am happy to have any inputs from others about different projects, though I think this is mainly up to us to decide how we do feature development, then we should find good practices for the selected way outside. Though I admit it might be worth it to check how other projects do it and what problem

Re: [DISCUSS] Feature branch vs Master based dev

+1 to keeping master shippable. In addition to config flags, for purposes of the upgrade finalization, many new features would need to be gated, one option would be to make the validators expect a version that is only possible by hand tweaking the version in a dev build, thus ensuring that unreleas

Re: [DISCUSS] Feature branch vs Master based dev

Our of curiosity, how other major Apache project do this? Like spark, nifi or airflow? Le lun. 25 avr. 2022 à 22:09, István Fajth a écrit : > Hi, > I was inspired with the latest discussions around compatibility guarantees, > and cutting a release to bring up a question about how we develop new

[DISCUSS] Feature branch vs Master based dev

Hi, I was inspired with the latest discussions around compatibility guarantees, and cutting a release to bring up a question about how we develop new features Currently we are using feature branches to start developing large new features. We see the drawbacks of this with long running developm

Re: [DISCUSS] 1.3.0 release

Hi, I also agree with Stephen and Ethan at least in that it is a bit early to cut a new release... I would even consider calling the new release 2.0.0 as so many new things are coming with it, it may be worth something bigger than a minor version bump. But Ethan is right, we have a couple of thin

Re: [DISCUSS] HDDS-6634 datanode doesn't check cluster identity in runtime

Thanks for replying. SCM is not moved anywhere. Let’s say we have a cluster A (datanode A, SCM A). Then we turn off master nodes of cluster A (note, that datanode A is still running) and bootstrap a new cluster B with an SCM B to be on the same IP address as SCM A was. And now we have SCM B that

Re: [VOTE] - Merge HDDS-4440-s3-performance feature branch into master

+1 for the merge. Thanks, Neil for working on this perf improvement feature for Ozone. Best, Sid On Mon, Apr 25, 2022 at 9:00 AM Uma Maheswara Rao Gangumalla < umaganguma...@gmail.com> wrote: > Oh, Looks like Attila covered those comments already. > > Post addressing those. +1 for the branch me

Re: [DISCUSS] HDDS-6634 datanode doesn't check cluster identity in runtime

Thanks for reporting the issue. The Datanodes can only contact the SCM with the same cluster ID. while moving the SCM, the metadata directories were also copied as well? Thanks, Mukul On 25/04/22 3:19 pm, Maxim Myskov wrote: Hi all, I would like to discuss https://issues.apache.org/jira/bro

Re: [VOTE] - Merge HDDS-4440-s3-performance feature branch into master

Oh, Looks like Attila covered those comments already. Post addressing those. +1 for the branch merge. Thanks for all the work here. Regards, Uma On Mon, Apr 25, 2022 at 8:58 AM Uma Maheswara Rao Gangumalla < umaganguma...@gmail.com> wrote: > Hi Neil, > > When I checked the above PR, I noticed

Re: [VOTE] - Merge HDDS-4440-s3-performance feature branch into master

Hi Neil, When I checked the above PR, I noticed a few checkstyle commits at the end. I am assuming you might know that we can't squash commits for branches as we lose the history of commits. So, those fixes should go as small JIRAs into your branch. Just use the git merge command to merge it to m

Re: [VOTE] - Merge HDDS-4440-s3-performance feature branch into master

+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

[DISCUSS] HDDS-6634 datanode doesn't check cluster identity in runtime

Hi all, I would like to discuss https://issues.apache.org/jira/browse/HDDS-6634 . During our internal Ozone testing, we noticed that a datanode can be connected to another cluster (not the one the datanode had been initialized with). Although the