Thanks, Elek. It's very good news to me that upgrade paths are always tested. Data formats are compatible across the versions.
BTW, last night, after I sent out previous mail, I was reminded of HDDS-4449, that changed the config key of Pipeline limit from ozone.datanode.pipeline.limit to ozone.scm.datanode.pipeline.limit . We set it as explicit value "36". If we had upgraded without changing the key, it would have been rolled back to default "2". That seems a kind of the case not tested in upgrade tests, because it's using default values in before and after the test upgrade. That's not critical in functionality, but it's critical to us in terms of performance. My worry is that there might be other changes like above - maybe reviewling around the ozone-default.xml and compare with previous release would help us, but I would welcome a lot if they are mentioned by developers. Automatically listing all possible keys and default values like in Hadoop [link] would be great, but my guess is that it's just the matter of priority and the number of hands. link: https://hadoop.apache.org/docs/r3.3.0/hadoop-project-dist/hadoop-hdfs/hdfs-default.xml Regards, Kota On Tue, Apr 20, 2021 at 7:08 PM Elek, Marton <e...@apache.org> wrote: > > > > On 4/20/21 9:02 AM, Kota Uenishi wrote: > > > We're planning to upgrade our bare metal cluster to 1.1.0 and want to > > know any important notice. I think I've seen some argument that > > rolling upgrade isn't supported on the path from 1.0 to 1.1. Is it > > straightforward like just injecting configuration XMLs to the > > ozone-1.1.0/etc/hadoop directory and restarting all process at once? I > > hope so, but things can easily go wrong and I want to be prepared. > > > Thanks to HDDS-3855 and HDDS-4741 (and other smaller patches) we have > upgrade test for each of the PR and master as part of the CI. > > I just double checked and the results can be found in the > acceptance-misc.zip artifact from any of the builds. > > This test creates data with older version of Ozone (0.5.0 or 1.0.0), > stops the cluster, and starts the actual version the same data directory. > > So the answer is yes: the upgrade supposed to be as easy as replacing > the ozone distribution (however making a backup from metadata dirs > couldn't be a mistake anytime ;-) ). > > > The soon-to-be-merged upgrade framework provides additional feature: You > can upgrade the jar files but keep the metadata compatible with the old > version as long as you testing new release. > > When you "finalize" this test period, the new features become available > and new style of metadata also will be used and persisted (which makes > it impossible to downgrade after this step). > > Marton > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org > For additional commands, e-mail: dev-h...@ozone.apache.org > -- -- Kota UENISHI, Engineer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org For additional commands, e-mail: dev-h...@ozone.apache.org
