On Thu, Sep 28, 2017 at 8:04 AM, Marios Andreou <[email protected]> wrote: > > > On Thu, Sep 28, 2017 at 9:50 AM, mathieu bultel <[email protected]> wrote: >> >> Hi, >> >> >> On 09/28/2017 05:05 AM, Emilien Macchi wrote: >> > I was reviewing https://review.openstack.org/#/c/487496/ and >> > https://review.openstack.org/#/c/487488/ when I realized that we still >> > didn't have any test coverage for minor updates. >> > We never had this coverage AFICT but this is not a reason to not push >> > forward it. >> Thank you for the review and the -2! :) >> So I'm agree with you, we need CI coverage for that part, and I was >> wondering how I can put quickly a test in CI for the minor update. >> But before that, just few things to take in account regarding those >> reviews: >> > > agree on the need for the ci coverage, but disagree on blocking this. by the > same logic we should not have landed anything minor update related during > the previous cycle. This is the very last part for > https://bugs.launchpad.net/tripleo/+bug/1715557 - wiring up the mechanism > into client and what's more matbu has managed to do it 'properly' with a > tripleo-common mistral action wired up to the tripleoclient cli. > > I don't think its right we don't have coverage but I also don't think its > right to block these last patches,
Yeah I agree - FWIW we have discussed this before, and AIUI the plan was: 1 - Get multinode coverage of an HA deployment with more than on controller (e.g the 3nodes job) but with containers enabled 2- Implement a rolling minor update test based on that multi-controller HA-with-containers test AFAIK we're only starting to get containers+pacemaker CI scenarios working with one controller, so it's not really reasonable to block this, since that is a prerequisite to the multi-controller test, which is a prerequisite to the rolling update test. Personally I think we'd be best to aim directly for the rolling update test in CI, as doing a single node minor update doesn't really test the most important aspect (e.g zero downtime). The other challenge here is the walltime relative to the CI timeout - we've been running into that for the containers upgrade job, and I think we need to figure out optimizations there which may also be required for minor update testing (maybe we can work around that by only updating a very small number of containers, but that will reduce the test coverage considerably?) I completely agree we need this coverage, and honestly we should have had it a long time ago, but we need to make progress on this last critical blocker for pike, while continuing to make progress on the CI coverage (which should certainly be a top priority for the Lifecycle squad, as soon as we have this completely new-for-pike minor updates workflow fully implemented and debugged). Thanks, Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
