As we are trying to do smart disaggregation of tests in the gate, I
think it's important to figure out which test configurations seem to be
actually helping, and which aren't. As the swift team has long had a
functional test job, this seems like a good place to start. (Also the
field deploy / upgrade story on Swift is probably one of the best of any
OpenStack project, so removing friction is probably in order.)

gate-swift-pep8 SUCCESS in 1m 16s
gate-swift-docs SUCCESS in 1m 48s
gate-swift-python27     SUCCESS in 3m 24s
check-tempest-dsvm-full SUCCESS in 56m 51s
check-tempest-dsvm-postgres-full        SUCCESS in 54m 53s
check-tempest-dsvm-neutron-full SUCCESS in 1h 06m 09s
check-tempest-dsvm-neutron-heat-slow    SUCCESS in 31m 18s
check-grenade-dsvm      SUCCESS in 39m 33s
gate-tempest-dsvm-large-ops     SUCCESS in 29m 34s
gate-tempest-dsvm-neutron-large-ops     SUCCESS in 22m 11s
gate-swift-tox-func     SUCCESS in 2m 50s (non-voting)
check-swift-dsvm-functional     SUCCESS in 17m 12s
check-devstack-dsvm-cells       SUCCESS in 15m 18s

I think in looking at that it's obvious that:
* check-devstack-dsvm-cells
* check-tempest-dsvm-postgres-full
* gate-tempest-dsvm-large-ops
* gate-tempest-dsvm-neutron-large-ops
* check-tempest-dsvm-neutron-full

Provide nothing new to swift, the access patterns on the glance => swift
interaction aren't impacted on any of those, neither is the heat / swift
resource tests or volumes / swift backup tests.

check-tempest-dsvm-neutron-heat-slow    doesn't touch swift either (it's
actually remarkably sparse of any content).

Which kind of leaves us with 1 full stack run, and the grenade job. Have
those caught real bugs? Does there remain value in them? Have other
teams that rely on swift found those to block regressions?

Let's figure out what's helpful, and what's not, and purge out all the
non helpful stuff.


Sean Dague

OpenStack-dev mailing list

Reply via email to