hi!
bertagaz@??? wrote (19 Jun 2012 11:39:17 GMT) :
>> > You also need a Jruby >= 1.6 environnement, which sadly isn't
>> > possible using debian packages yet
>>
>> Any hint / idea / pointer why?
> See bug #636554, the maintainer seems to say back in september 2011
> that he is willing to upload jruby 1.6 "*after* the testing
> migration". Not sure what he means by that, probably after wheeze is
> released. Adding a word on this bug is prolly a good idea, so if you
> want to you're welcome.
Done. Let's see what it triggers, if any at all.
>> > but anyway you need this gems to be installed
>>
>> Do you want to {add references to,file} the corresponsding RFP bugs,
>> or shall I?
> As you wish. As long as jruby is < 1.6 in Debian at least the sikuli
> gem won't be packageable anyway. Might help to get a jruby upgrade.
Well, if you don't mind, please reference or file the RFP bugs
yourself, then :)
>> > setup a basic VM
>>
>> Providing a guest XML skeleton would be perfect :)
> Yeah, that's one of the questions brought by this tool. Might be usefull
> if it contains a basic domain definition for sure. For consistency of
> devices name for example.
> To test different feature, there will be need for diffferent VMs
> configurations, for example some with more memory for the memory wiping
> on shutdown feature. There are mainly two different ways to achieve this:
> * programatically by using libvirt ruby bindings and use the functions to
> attach/remove devices, modify the basic VM configuration, etc, which is
> the current roughly implemented way.
> * enable the tests to be shipped with a full domain definition, that would
> be automatically loaded rather than a default one.
> Between the two, tests could be shipped only with xml domain snippet
> corresponding to the configuration changes to be done on the domain.
> The second one would be the easiest, and might have the advantage to be a
> totally "stop and throw away this domain" solution, so would help not to
> modify too much the domain definition and keep consistency upon tests. But
> there might be drawbacks too in this implementation.
I tend to prefer the 2nd way too, for the sake of reproducibility.
I suggest we try it, and see how it goes.
Regardless how the initial domain definition is done, we'll probably
need to programatically change it while testing,
e.g. to plug or unplug a USB device.
So the programmatic interface is good news anyway.
Side question: how often to reboot the tested system?
cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
