Open Stack

On Wed, Nov 13, 2013 at 11:11 AM, Sean Dague <sean at dague.net> wrote:

> 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.
>

Good point.


>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/1c86ea9f/attachment.html>