[openstack-dev] disable/enable services and agent tests

Sean Dague sean at dague.net
Wed Nov 13 19:11:13 UTC 2013


On 11/13/2013 02:06 PM, Joe Gordon wrote:
> 
> 
> 
> On Wed, Nov 13, 2013 at 8:18 PM, Sean Dague <sean at dague.net
> <mailto:sean at dague.net>> wrote:
> 
>     On 11/12/2013 10:25 PM, Robert Collins wrote:
>     > We shouldn't really be changing the config of the cloud we're testing
>     > - that stops us being run against actual prod clouds.
>     >
>     > Instead we should have some set of profiles we test against - and then
>     > run different jobs for different profiles, avoiding the problem
>     > entirely.
> 
>     The issue here is we've got an API that's exposed to the admin to do
>     this, which means for some folks, it would be nice to test this
>     functionality is working. Per our community mantra "If it's not tested,
>     it's assumed broken." -
>     https://twitter.com/russellbryant/status/396889282155008000
> 
>     That being said, in this case in particular, we should probably be more
>     careful about disabling our only nova-compute during the tests, because,
>     you know, that might be bad. Today the calls happen so quickly, I think
>     we've just avoided the race entirely (the enable_disable test has been
>     in the gate since H2). I've honestly never seen a race that we can track
>     down to this in the gate.
> 
>     For now, I'd agree that enable_disable should probably be removed from a
>     normal tempest run. I think we've started to find that we have a class
>     of APIs that impact our runtime in a dramatic enough way, that we need
>     to be really careful about how we tickle them. I'd be interested in
>     ideas about how we do that. Remember we also have locking in our bag of
>     tricks, which is what we need to do around all the aggregate tests, as
>     those are admin tests on global state.
> 
> 
> Why not just use the lock in this case?

Well... the only issue is we'd actually have to also lock every compute
call that would get to n-cpu, because the resource we are making go away
is n-cpu. Which is a ton of lock metering for one test.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/02eb2058/attachment.pgp>


More information about the OpenStack-dev mailing list