Open Stack

On Wed, Dec 11, 2013 at 01:44:19PM +0100, Giulio Fidente wrote:
> hi,
> 
> I'm attempting to rationalize on the status of tempest blueprints. I
> need your help so I organized questions in a few open points.
> 
> 
> * (1) I'm looking for input here on the actual status of the
> following blueprints, which are already approved or in a good
> progress state:
> 
> https://blueprints.launchpad.net/tempest/+spec/add-basic-heat-tests
> 
> seems done, shall we close it? (steve baker)
> 
> https://blueprints.launchpad.net/tempest/+spec/fail-gate-on-log-errors
> 
> seems done, shall we close it? (david kranz)
> 
> https://blueprints.launchpad.net/tempest/+spec/config-cleanup
> https://blueprints.launchpad.net/tempest/+spec/config-verification
> 
> seems done, close? (mtreinish)

These are both still in progress. The config verification tooling one is
dependent on the config file format being finalized. All that it has right now
is basic framework to build off of.

> 
> https://blueprints.launchpad.net/tempest/+spec/fix-gate-tempest-devstack-vm-quantum-full
> 
> old but still valid for icehouse, what is the real status here? (mlavalle)
> 
> https://blueprints.launchpad.net/tempest/+spec/client-lib-stability
> 
> is slow progress appropriate here? (david kranz)
> 
> https://blueprints.launchpad.net/tempest/+spec/quantum-basic-api
> 
> this was approved but it looks to me quite hard to implement tests
> for the different network topologies, is it even possible given our
> infra? (mlavalle)
> 
> https://blueprints.launchpad.net/tempest/+spec/crash-scenario-generator
> 
> needs approval, is there any agreement upon this being implemented
> or shall we drop this? (all core and contributors)
> 
> https://blueprints.launchpad.net/tempest/+spec/missing-compute-api-extensions
> 
> identifying missing tests isn't a blueprint per se I think so I'd
> close this unless someone volunteer the work to at least identify
> the wanted tests
> 
> 
> * (2) The following are instead blueprints open for discussion which
> I think should either be approved or closed, again input is more
> than welcomed as well as assignees if you care about it:
> 
> https://blueprints.launchpad.net/tempest/+spec/refactor-rest-client

I'm going to reject this one. It seems to comes up every cycle, but because
of the differences between XML/JSON having a common client just ends up
being more work. I remember a ML thread on this topic several months ago.

> 
> https://blueprints.launchpad.net/tempest/+spec/tempest-multiple-images

This is an old one, we have multi-image test support in tempest. Although I'm
sure it could be better. It's probably safe to close it.

> 
> https://blueprints.launchpad.net/tempest/+spec/general-swift-client

Not being very familiar with the swift API I can't say how much simpler
having a single client for all the resource types would be. You should cycle
back around with Martina Kollarova and get some more details about what he's
planning.

> 
> https://blueprints.launchpad.net/tempest/+spec/input-scenarios-for-scenario

This was approved during last week's meeting.

> 
> https://blueprints.launchpad.net/tempest/+spec/neutron-advanced-scenarios

This should be approved.

> 
> https://blueprints.launchpad.net/tempest/+spec/stress-api-tracking

I'd defer to mkoderer on this one, but it sounds reasonable to me.

> 
> https://blueprints.launchpad.net/tempest/+spec/test-developer-documentation

We definitely need more documentation for tempest. But, I think this needs a
better description and a concrete list of work items though. I don't think the
definition of a negative test is really a big issue when it comes to tempest
documentation.

> 
> 
> * (3) Finally, as a general rule of thumb for the many remaining
> blueprints which only demand for new tests, I think we should keep
> and approve blueprints asking for basic tests around new components
> but *not* (as in close) blueprints demanding for additional tests
> around existing components. Does it look reasonable?

I think this is fine, although we probably need a better story around adding
tests to prevent duplication of effort.

-Matt Treinish