OST: A good way to test cluster compatibility version upgrade?
Hi, we'd like to test cluster compatibility version upgrades in OST and we're thinking whether there is a good way to do that without putting much burden on OST. We want to test that the cluster updates without errors, as well as the VMs in it. A safe way would be to create a new data center for that purpose and run the test on it. But some operations, such as adding a host or a storage, are slow. Maybe we could initialize the data center in parallel with the current test data center but then we'd need an additional Lago host, which might increase memory requirements, already high enough. We might create a new data center and cluster without running hosts and running VMs but then the test would be limited in its extent. Another possibility is to reuse the current test data center. We could create it with the oldest support compatibility version, rather than current compatibility version, and perform upgrades on it up to the current compatibility version. Then we would continue with the tests normally. The overhead, besides testing the upgrades themselves, could be minimal. The disadvantage would be that we wouldn't test the current-compatibility-version creation process directly. We could also make a separate test suite for that test, but is it desirable and would anybody run it regularly? So what do you recommend as a good way to test cluster compatibility version upgrades? Thanks, Milan
On 7 August 2017 at 18:00, Milan Zamazal <mzamazal@redhat.com> wrote:
We could also make a separate test suite for that test, but is it desirable and would anybody run it regularly?
So what do you recommend as a good way to test cluster compatibility version upgrades?
Maybe we could add this to the upgrade suits? They are currently only running engine, but I guess hosts could be added and the suits could be expanded to cover the entire upgrade process and not just engine's. The upgrade suits are already getting run automatically by the change queue alongside the basic suit. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
As Barak said, I think it's a good idea to try and extend the current upgrade suites. As the upgrade suites are already running in parallel (on different hosts) with the basic_suite (and currently the upgrade suite is much faster than the basic suite), we might end up with the same run time as the basic suite, which eventually won't increase the total time of change queue's tests. On Mon, Aug 7, 2017 at 6:06 PM, Barak Korren <bkorren@redhat.com> wrote:
On 7 August 2017 at 18:00, Milan Zamazal <mzamazal@redhat.com> wrote:
We could also make a separate test suite for that test, but is it desirable and would anybody run it regularly?
So what do you recommend as a good way to test cluster compatibility version upgrades?
Maybe we could add this to the upgrade suits? They are currently only running engine, but I guess hosts could be added and the suits could be expanded to cover the entire upgrade process and not just engine's.
The upgrade suits are already getting run automatically by the change queue alongside the basic suit.
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- DANIEL BELENKY RHV DEVOPS EMEA VIRTUALIZATION R&D <https://red.ht/sig>
Daniel Belenky <dbelenky@redhat.com> writes:
As Barak said, I think it's a good idea to try and extend the current upgrade suites. As the upgrade suites are already running in parallel (on different hosts) with the basic_suite (and currently the upgrade suite is much faster than the basic suite), we might end up with the same run time as the basic suite, which eventually won't increase the total time of change queue's tests.
Thank you both for the advice, under those circumstances the upgrade suite should be a very good place, so we'll use it. Thanks, Milan
Hi Milan, Please feel free to ping me if you'll need assistance with the structure of the upgrade suites. Thanks, On Mon, Aug 7, 2017 at 10:09 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
Daniel Belenky <dbelenky@redhat.com> writes:
As Barak said, I think it's a good idea to try and extend the current upgrade suites. As the upgrade suites are already running in parallel (on different hosts) with the basic_suite (and currently the upgrade suite is much faster than the basic suite), we might end up with the same run time as the basic suite, which eventually won't increase the total time of change queue's tests.
Thank you both for the advice, under those circumstances the upgrade suite should be a very good place, so we'll use it.
Thanks, Milan
-- DANIEL BELENKY RHV DEVOPS EMEA VIRTUALIZATION R&D <https://red.ht/sig>
participants (3)
-
Barak Korren -
Daniel Belenky -
Milan Zamazal