Open Stack

haha ... worse email thread ever. 

I'll catch you on IRC ... we've diverged too far to make sense.

-S
________________________________________
From: Soren Hansen [soren at linux2go.dk]
Sent: Wednesday, November 23, 2011 6:30 PM
To: Sandy Walsh
Cc: openstack at lists.launchpad.net
Subject: Re: [Openstack] [nova-testing] Efforts for Essex

2011/11/23 Sandy Walsh <sandy.walsh at rackspace.com>:
> I understand what you're proposing, but I'm backtracking a little.
> (my kingdom for you and a whiteboard in the same room :)

Well, IRC would be a good start. :) I haven't seen you on IRC for days?

> I think that you could have a hybrid of your
> db.do_something("desired_return_value")

I may be reading too much into this, but this example suggests you're
not following me, to be honest.

db.instance_create is not a method I'm adding. It is an existing
method. It's the method you use to add an instance to the data store,
so it's not so much about passing it "desired return values". It's
about adding an instance to the database in the exactly same fashion
as production could would have done it, thus allowing subsequent calls
to instance_get (or any of the ~30 other methods that return one or
more Instance objects) to return it appropriately. And by
appropriately, I mean: with all the same attributes as one of the real
db drivers would have returned.

> to produce:
> self.sorens_mox.Set(nova.db, 'instance_get_by_uuid', {'name': 'this or that',
>                'instance_type_id': 42})

We have this functionality today. My example:

   self.stubs.Set(nova.db, 'instance_get_by_uuid', fake_instance_get)

was copied from one of our existing tests.

--
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/