On 10/31/18 2:57 PM, Julia Kreger wrote:
On Wed, Oct 31, 2018 at 5:44 AM Dmitry Tantsur <dtant...@redhat.com
<mailto:dtant...@redhat.com>> wrote:
Hi,
On 10/31/18 1:36 AM, Julia Kreger wrote:
[trim]
>
> ironic-tempest-dsvm-ipa-wholedisk-agent_ipmitool-tinyipa-multinode - This
job is
> essentially the same as our grenade mutlinode job, the only difference
being
> grenade.
Nope, not the same. Grenade jobs run only smoke tests, this job runs
https://github.com/openstack/ironic-tempest-plugin/blob/master/ironic_tempest_plugin/tests/scenario/test_baremetal_multitenancy.py
Ugh, Looking closer, we still end up deploying when the smoke tests run. It
feels like the only real difference between what is being exercised is that one
our explicit test scenario of putting two instances on two separate networks and
validating connectivity is not present between the two. I guess I'm failing to
see why we need all of the setup and infrastructure when we're just testing
pluggable network bits and settings their upon. Maybe it is a good cantidate for
looking at evolving how we handle scenario testing so we reduce our gate load
and resulting wait for test results.
> ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa - This job
> essentially just duplicates the functionality already covered in other
jobs,
> including the grenade job.
Ditto, grenade jobs do not cover our tests at all. Also this is the very
job we
run on other projects (nova, neutron, maybe more), so it will be a bit
painful
to remove it.
We run the basic baremetal ops test, which tests deploy. If we're already
covering the same code paths in other tests (which I feel we are), then the test
feels redundant to me. I'm not worried about the effort to change the job in
other gates. We really need to pull agent_ipmitool out of the name if we keep it
anyway... which still means going through zuul configs.
Do not smoke tests cover rescue with bare metal? Because our jobs do.
[trim]
__________________________________________________________________________
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
