Re: [Engine-devel] data modelling in fixtures.xml

2012-01-25 Thread Yair Zaslavsky
On 01/25/2012 09:58 AM, Mike Kolesnik wrote:
 
 - Original Message -
 Hi all,
 When you introduce new business entities + DAOs or change some
 behaviour
 of existing ones, besides providing tests, please try as much as
 possible to insert reasonable test data to fixtures.xml, as we use
 the
 same fixtures.xml file for all our DAO testing.
 
 Regarding that, perhaps we should use separate fixtures for different tests, 
 so that they're lees dependant on each other (in terms of predefined data).
I agree, this is definitely something we should check how to do using
DbUnit.

 

 Kind regards,
 Yair
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


Re: [Engine-devel] VM Payload feature

2012-01-25 Thread Dor Laor

On 01/22/2012 08:42 PM, Ayal Baron wrote:



- Original Message -



- Original Message -

From: Ayal Baronaba...@redhat.com
To: Oved Ourfalliov...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Thursday, January 19, 2012 4:05:08 PM
Subject: Re: [Engine-devel] VM Payload feature



- Original Message -

Hey all,

Continuing the discussion about Aeolus instance data injection to
a
VM
(http://lists.ovirt.org/pipermail/engine-devel/2012-January/000423.html)
we propose a new VM Payload feature.

The following wiki page contains a description page of the
feature.
http://www.ovirt.org/wiki/Features/VMPayload

Please read and review.
There are several approaches there, and we wish to head your
opinions
and thoughts about them.

Once we agree on an approach, we will start designing.


Permanent payload availability requires determining where the
payload
is stored.
Makes sense to me to store it together with the VM disks on the
storage domain, but that requires the small object store which will
not be available in the coming version (payloads can be large and
keeping them in the DB and passing over the net every time the VM
is
run doesn't make much sense).


I guess we can start with storing it in the database, with some size
limitation, and move it to the storage domain later on.


If Aeolus and Deltacloud don't need the permanent payload feature then no need 
to store it at all and then just add this capability later on properly.


Currently it seems that there are too many options for it - floppy, cd, 
nfs and maybe more. It would be nice to have a single option that works 
for all cases. How about creating something like s3 compatible storage 
access that the guest can access? If you need boot time access then I'll 
recommend cdrom or plain virtio-blk.







Wrt availability, I don't see a reason to exclude attaching both a
CD
and a payload via another CD at the same time (i.e. multiple
devices).



Thank you,
Oved
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel




___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel