One more bear on the road: account for object name clashing; if you create
an test_vm in your test and it already existed... you'll have to somehow
gather objects by uuid and only use those.
/me being paranoid and budding into other peoples' project plans,
Daan
On Wed, Sep 10, 2014 at 4:05 PM, A
> I like the idea. What worries me is the possibility to run test cases on a
> life
> system. I think it is useful for some operators to be able to do that.
> Those people must not lose any objects that were created outside of the
> test suite. Therefore it can be very tricky, not very different f
Alex,
I like the idea. What worries me is the possibility to run test cases on a
life system. I think it is useful for some operators to be able to do that.
Those people must not lose any objects that were created outside of the
test suite. Therefore it can be very tricky, not very different from
One thing that is important to consider here is "order in which we cleanup
resources". Many times, cleanup operation fails if the resource can't be
deleted unless few other resources are deleted (child/dependent).
Alex, if you think if this too can be handled efficiently with the
prototype you are
On Wed, Sep 10, 2014 at 5:42 AM, Alex Brett wrote:
> Hello all,
>
> At the moment we have a lot of Marvin tests that follow a pattern that looks
> roughly like this:
>
> 1. Setup some resources (e.g. accounts, service offerings, VMs etc)
> 2. Add the resources to a list in the testcase (often cal
Hello all,
At the moment we have a lot of Marvin tests that follow a pattern that looks
roughly like this:
1. Setup some resources (e.g. accounts, service offerings, VMs etc)
2. Add the resources to a list in the testcase (often called self.cleanup)
3. Do the test(s)
4. Call cleanup_resources wi
