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.
-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
--
Sean Dague
http://dague.net
__________________________________________________________________________
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
