You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ozone.apache.org by Aravindan Vijayan <av...@cloudera.com.INVALID> on 2021/05/10 05:32:38 UTC
Re: [VOTE] - Merge Non rolling upgrade branch - 'HDDS-3698-nonrolling-upgrade'
Hello Marton,
Apologies for the delayed response, your reply slipped through my attention!
I am not sure which of my statements conveyed the fact that we want to
"stabilize" on the master. We have been continuously stabilizing the branch
for the last 2 months while keeping an eye on regressions, code quality and
CI stability. When we set out to work on HDDS-3698, we had some goals and I
believe those have been met. The bugs that were reported by you are being
worked on or fixed (including the security issue which is only on the
upgrade path, and not on the regular path). IMHO, if everyone waits for
100% correctness to merge a feature, then the master will never be up to
date.
We are working on the (hopefully) final merge from master, and then we will
create the merge commit from the branch after that. If large scale changes
are expected after the VOTE, I believe as project PMC/committers we would
let the dev know. I am sure we are not trying to get approval for 'A', and
then merge 'B'.
On Fri, Apr 23, 2021 at 4:08 AM guimark <gu...@126.com> wrote:
>
>
>
>
>
>
>
>
> I started to contribute to this feature these days, in my opinion, the
> framework of the feature itself is stable
> and will not do harm to any other parts. And it is a really big step
> towards the future 'rolling upgrade'.
> As elek pointed, there are some issues needs to be fixed, and I'd be very
> glad to help fix them :)
>
>
>
>
>
>
>
> At 2021-04-23 10:37:20, "Aravindan Vijayan" <av...@cloudera.com.INVALID>
> wrote:
> >Since I do not see any objections to the DISCUSS thread, moving this to
> >VOTE thread.
> >
> >On Mon, Apr 19, 2021 at 10:04 AM Aravindan Vijayan <avijayan@cloudera.com
> >
> >wrote:
> >
> >> Hello all,
> >>
> >> I would like to propose merging the work done for supporting non rolling
> >> upgrades in Ozone (HDDS-3698-nonrolling-upgrade) into the Ozone master
> >> branch.
> >>
> >> As part of the upgrade framework, the following have been added
> >>
> >> - Ability to create layout features & versions
> >> - Ability to finalize and upgrade an Ozone cluster, as well as
> >> downgrade before finalization.
> >> - Ability to add custom actions to be executed as upgrade hooks in
> >> different phases.
> >> - Ability to 'prepare' an Ozone manager quorum for upgrade.
> >>
> >> We believe that the branch is ready for merge due to the following
> reasons
> >>
> >> - We have resolved around 60 JIRAs (including 6 Apache Ratis fixes).
> >> There are about 3-4 remaining JIRAs that are currently in progress
> (or
> >> under review) which are not blockers and are close to completion.
> >> - The merge checklist has been looked at and filled in at
> >>
> https://cwiki.apache.org/confluence/display/OZONE/Non-Rolling+Upgrade+Framework+Merge+Checklist
> >> .
> >> - A broad range of test cases have been added including unit tests,
> >> integration tests to perform finalization & upgrade, failure
> injection
> >> testing in HDDS layer finalization and acceptance tests to perform a
> >> prepare operation and a docker based upgrade flow from the last
> released
> >> version to current.
> >> - Sufficient documentation has been added for the design (here
> >> <
> https://issues.apache.org/jira/secure/attachment/13023446/Ozone%20Non-Rolling%20Upgrades%20Doc%20v1.2%20%28Implemented%20Design%29.pdf
> >
> >> & here
> >> <
> https://issues.apache.org/jira/secure/attachment/13015490/OM%20Prepare%20Upgrade.pdf
> >),
> >> usage (here
> >> <
> https://github.com/apache/ozone/blob/HDDS-3698-nonrolling-upgrade/hadoop-hdds/docs/content/feature/how-to-do-a-nonrolling-upgrade.md
> >)
> >> and developer primer (here
> >> <
> https://github.com/apache/ozone/blob/HDDS-3698-nonrolling-upgrade/hadoop-hdds/docs/content/design/upgrade-dev-primer.md
> >
> >> ).
> >>
> >> There is some work needed to onboard the work done for HDDS-2939 into
> the
> >> upgrade branch. If that branch is merged first, then the onboarding can
> be
> >> done before the upgrade branch merge through a single patch.
> >>
> >> Please provide your feedback. If there are no objections, I will proceed
> >> with starting a vote thread for merging.
> >>
> >> --
> >> Thanks & Regards,
> >> Aravindan
> >>
> >
> >
> >--
> >Thanks & Regards,
> >Aravindan
>
--
Thanks & Regards,
Aravindan
Re: [VOTE] - Merge Non rolling upgrade branch -
'HDDS-3698-nonrolling-upgrade'
Posted by Mukul Kumar Singh <mk...@gmail.com>.
+1
Thanks,
Mukul
On 21/06/21 8:10 pm, Aravindan Vijayan wrote:
> Hello All,
>
> Circling back to the upgrade branch VOTE thread after fixing issues
> mentioned from last vote, and incorporating changes from HDDS-2939. Please
> refer to the original VOTE mail for the details of the design and
> implementation.
>
> The github feature branch is here:
> https://github.com/apache/ozone/tree/HDDS-3698-nonrolling-upgrade
>
> The design documents as well as feature documentation is put up in the
> ozone wiki:
> https://cwiki.apache.org/confluence/display/OZONE/Non-Rolling+Upgrade+Framework+Merge+Checklist
>
> The merge discussion thread is:
> https://lists.apache.org/thread.html/r463b8f2742994c2f1596541d49d0340c88817958c530bf10694e6a9c%40%3Cdev.ozone.apache.org%3E
>
> Thanks to all contributors for your input into the design, implementing,
> testing and review of this feature.
>
> I am starting with my +1.
>
> *The vote will run for 7 days, ending on June 28th 2021 at 8:00 am PT.*
>
> On Mon, May 17, 2021 at 8:03 AM Elek, Marton <el...@apache.org> wrote:
>
>> Thanks the answer Aravindan.
>>
>>> If large scale changes
>>> are expected after the VOTE, I believe as project PMC/committers we would
>>> let the dev know. I am sure we are not trying to get approval for 'A',
>> and
>>> then merge 'B'.
>> Just let me clarify it: I am not concerned about large changes after
>> VOTE. We already discussed the design and we had a strong agreement.
>>
>> I am concerned about the small issues which can be fixed easily. But
>> here, the power of the community can help: with the following two inputs
>> everybody can help to do a final test:
>>
>> * at least a basic documentation (we have it)
>> * A commit proposed to be merged (to make it possible to compare the
>> results)
>>
>> This is very similar to what we do for each release. Just do a final
>> smoke check to be sure we are fine.
>>
>> And similar to a release, one small commit can be a big difference (a
>> wrong LICENSE can be a release blocker, or one very unstable test can be
>> a merge blocker ).
>>
>> That's the reason why I asked for a commit hash: a well-specified plan
>> to vote on. (but as far as I remember I was not the only one...)
>>
>> Thanks again the answer and the great work,
>> Marton
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
>> For additional commands, e-mail: dev-help@ozone.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [VOTE] - Merge Non rolling upgrade branch - 'HDDS-3698-nonrolling-upgrade'
Posted by Aravindan Vijayan <av...@cloudera.com.INVALID>.
Hello All,
Circling back to the upgrade branch VOTE thread after fixing issues
mentioned from last vote, and incorporating changes from HDDS-2939. Please
refer to the original VOTE mail for the details of the design and
implementation.
The github feature branch is here:
https://github.com/apache/ozone/tree/HDDS-3698-nonrolling-upgrade
The design documents as well as feature documentation is put up in the
ozone wiki:
https://cwiki.apache.org/confluence/display/OZONE/Non-Rolling+Upgrade+Framework+Merge+Checklist
The merge discussion thread is:
https://lists.apache.org/thread.html/r463b8f2742994c2f1596541d49d0340c88817958c530bf10694e6a9c%40%3Cdev.ozone.apache.org%3E
Thanks to all contributors for your input into the design, implementing,
testing and review of this feature.
I am starting with my +1.
*The vote will run for 7 days, ending on June 28th 2021 at 8:00 am PT.*
On Mon, May 17, 2021 at 8:03 AM Elek, Marton <el...@apache.org> wrote:
> Thanks the answer Aravindan.
>
> > If large scale changes
> > are expected after the VOTE, I believe as project PMC/committers we would
> > let the dev know. I am sure we are not trying to get approval for 'A',
> and
> > then merge 'B'.
>
> Just let me clarify it: I am not concerned about large changes after
> VOTE. We already discussed the design and we had a strong agreement.
>
> I am concerned about the small issues which can be fixed easily. But
> here, the power of the community can help: with the following two inputs
> everybody can help to do a final test:
>
> * at least a basic documentation (we have it)
> * A commit proposed to be merged (to make it possible to compare the
> results)
>
> This is very similar to what we do for each release. Just do a final
> smoke check to be sure we are fine.
>
> And similar to a release, one small commit can be a big difference (a
> wrong LICENSE can be a release blocker, or one very unstable test can be
> a merge blocker ).
>
> That's the reason why I asked for a commit hash: a well-specified plan
> to vote on. (but as far as I remember I was not the only one...)
>
> Thanks again the answer and the great work,
> Marton
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> For additional commands, e-mail: dev-help@ozone.apache.org
>
>
--
Thanks & Regards,
Aravindan
Re: [VOTE] - Merge Non rolling upgrade branch -
'HDDS-3698-nonrolling-upgrade'
Posted by "Elek, Marton" <el...@apache.org>.
Thanks the answer Aravindan.
> If large scale changes
> are expected after the VOTE, I believe as project PMC/committers we would
> let the dev know. I am sure we are not trying to get approval for 'A', and
> then merge 'B'.
Just let me clarify it: I am not concerned about large changes after
VOTE. We already discussed the design and we had a strong agreement.
I am concerned about the small issues which can be fixed easily. But
here, the power of the community can help: with the following two inputs
everybody can help to do a final test:
* at least a basic documentation (we have it)
* A commit proposed to be merged (to make it possible to compare the
results)
This is very similar to what we do for each release. Just do a final
smoke check to be sure we are fine.
And similar to a release, one small commit can be a big difference (a
wrong LICENSE can be a release blocker, or one very unstable test can be
a merge blocker ).
That's the reason why I asked for a commit hash: a well-specified plan
to vote on. (but as far as I remember I was not the only one...)
Thanks again the answer and the great work,
Marton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org