On 6/15/2016 5:17 AM, Evgeny Antyshev wrote:
Hello, Matt!
First of all, I want to apologize for the inconvenience.
This all started yesterday when I updated Virtuozzo CI using latest
puppets, Zuul, Jenkins and other stuff.
The update somehow led to Zuul not passing environment variables like
ZUUL_CHANGE, LOG_PATH to Jenkins job.
Therefore, devstack-gate didn't apply the change 282580 which triggered
the test (usually it does).
I'm still investigating this issue with Zuul-Jenkins interaction.
Please, also see inline comments:
On 06/15/2016 12:51 AM, Matt Riedemann wrote:
It was pointed out today in IRC that the Virtuozzo CI has been failing
on this change for the libvirt imagebackend refactor:
https://review.openstack.org/#/c/282580/
Diana was having a hard time sorting out the line numbers in the stack
trace though from the logs, because they didn't exist in her series.
Long story short, that's because the job checks to see if the change
is the change that adds resize support for virtuozzo:
https://review.openstack.org/#/c/182257/
And if not, it fetches that change:
23:48:46 2016-06-10 23:48:58.863 | + cd /opt/stack/new/nova
23:48:46 2016-06-10 23:48:58.872 | + [[ 282580 -ne 182257 ]]
23:48:46 2016-06-10 23:48:58.875 | + git fetch
https://review.openstack.org/p/openstack/nova refs/changes/57/182257/37
23:48:59 2016-06-10 23:49:11.357 | From
https://review.openstack.org/p/openstack/nova
23:48:59 2016-06-10 23:49:11.359 | * branch refs/changes/57/182257/37
-> FETCH_HEAD
23:48:59 2016-06-10 23:49:11.366 | + git cherry-pick FETCH_HEAD
23:48:59 2016-06-10 23:49:11.689 | [detached HEAD 44b6772] libvirt:
virtuozzo instance resize support
It's not valid to patch Nova for your CI when testing other changes,
it breaks the whole point of CI testing if you have to patch things in
it that aren't in the actual dependency change or repo - because when
it fails, like in this case, one doesn't know if it's their actual
change that's broken or the patch in the CI job.
Well, this methodology is explained in
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
("How do I run my CI to test all cinder patches with my driver not yet
merged?")
I hoped the same approach is valid for Nova.
The change 182257 is critical for our functionality, but is not merged yet.
Should we test other patches assuming our change got merged, or not is a
policy question,
and it is obvious that in Cinder this is regarded as normal.
It's different when you're adding a new driver that's not yet in tree.
The virtuozzo support is already in the libvirt driver. The team is
working on feature parity, which is good, but you should be able to run
other basic server tests (create/delete/start/stop/etc) on all nova
changes. The resize tests should only run on the patch that adds the
resize support.
I'm assuming this was done because I asked for the Virtuozzo CI to run
the resize tests in tempest against
https://review.openstack.org/#/c/182257/ - which it is, but that
didn't mean also do it for all other changes in Nova. The CI job
should conditionally enable those tests when testing change 182257 but
not anything else until that's merged.
If you confirm this, I'll do as you explained above.
Correct, you should only test resize against the patch that adds the
resize support and nothing else until that change is merged. This should
be somewhat trivial by setting the CONF.compute_feature_enabled.resize
flag in tempest.conf.
As a side note, the job isn't fetching the latest patch set of the
resize change anyway, at least not as of last week, it's fetching
patch set 37 but 39 is the latest.
Well, fixing this was a part of an update procedure which led to such
dramatic consequences.
Anyway, this isn't meant to shame, but to inform and correct. No one
from the Virtuozzo team was in the nova IRC channel when we discovered
this, so I needed to get it into the dev list.
But please get this fixed ASAP since it's invalidating the Virtuozzo
CI results.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
