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
--
Sean Dague
http://dague.net
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
