On 09/26/2016 01:09 PM, Sean Dague wrote:
This should probably be set at the job level, and not buried inside
devstack to be different based on hypervisor. That's going to be a lot
more confusing to unwind later.
Fair. So should we just set DEVSTACK_GATE_CONFIGDRIVE for all our jobs? Do you
think it should go somewhere here:
https://github.com/openstack-infra/devstack-gate/blob/7ecc7dd4067d99e0fa7525a9fffc8b05e1a7b58f/devstack-vm-gate.sh#L343-L370
?
-Sean
On 09/26/2016 04:55 AM, Dmitry Tantsur wrote:
Just bringing QA folks attention: please merge
https://review.openstack.org/#/c/375467/ as we've regressed in our
testing coverage (see below for details).
On 09/23/2016 08:21 PM, Jim Rollenhagen wrote:
On Fri, Sep 23, 2016 at 7:37 AM, Dmitry Tantsur <dtant...@redhat.com>
wrote:
Hi folks!
We've found out that we're not testing creating of config drives in
our CI.
It ended up in one combination being actually broken (pxe_* +
wholedisk +
configdrive). I would like to cover this testing gap. Is there any
benefit
in NOT using config drives in all jobs? I assume we should not bother
too
much testing the metadata service, as it's not within our code base
(unlike
config drive).
I've proposed https://review.openstack.org/375362 to switch our tempest
plugin to testing config drives, please vote. As you see one job
fails on it
- this is the breakage I was talking about. It will (hopefully) get
fixed
with the next release of ironic-lib.
Right, so as Pavlo mentioned in the patch, configdrive used to be the
default
for devstack, and as such we forced configdrive for all tests. When
that was
changed, we didn't notice because somehow metadata service worked.
https://github.com/openstack-dev/devstack/commit/7682ea88a6ab8693b215646f16748dbbc2476cc4
I agree, we should go back to using configdrive for all tests.
// jim
Finally, we need to run all jobs on ironic-lib, not only one, as
ironic-lib
is not the basis for all deployment variants. This will probably happen
after we switch our DSVM jobs to Xenial though.
-- Dmitry
__________________________________________________________________________
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
__________________________________________________________________________
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
__________________________________________________________________________
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
__________________________________________________________________________
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
