From: Mike Burns <mburns@redhat.com>
To: Eduardo Pereira Habkost <ehabkost@redhat.com>
Cc: Michael Goldish <mgoldish@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Uri Lublin <ulublin@redhat.com>
Subject: Re: [PATCH][KVM-AUTOTEST] Add custom install option for kvm_install
Date: Tue, 12 May 2009 11:28:32 -0400 [thread overview]
Message-ID: <4A0995A0.8040302@redhat.com> (raw)
In-Reply-To: <1242068979-sup-1532@blackpad>
Eduardo Pereira Habkost wrote:
> Excerpts from Michael Goldish's message of Mon May 11 16:00:29 -0300 2009:
>
>> ----- "Eduardo Habkost" <ehabkost@redhat.com> wrote:
>>
>>
> <snip>
>
>>> Also, can't the install rule be used on the cartesian configuration
>>> file? In this case, the install parameters may be specified on a
>>> different config rule.
>>>
>> It's certainly possible. We chose to put kvm_install in the control
>> file because currently it's the only test we run only once per job.
>> There is no natural place for kvm_install in kvm_tests.cfg because
>> everything else there gets multiplied.
>>
>
> True. I haven't thought of that.
>
>
>>> For example, the Fedora project could use it like this:
>>>
>>> cvs_server = "cvs.fedoraproject.org:/..."
>>> variants:
>>> - CVSF10:
>>> cvs_branch = F10
>>> - CVSF11:
>>> cvs_branch = F11
>>> - CVSRawhide:
>>> cvs_branch = devel
>>>
>>>
>>> variants:
>>> - install:
>>> type = kvm_install
>>> mode = custom
>>> install_command = "install_from_fedora_cvs.sh"
>>> - ...
>>>
>>> I used Fedora CVS as an example, but the user may use anything we can
>>> imagine, to store KVM code (or pointer to its), possibly having
>>> different branches.
>>>
>> This can be done, though the order and syntax of the 'variants' blocks
>> should be different, more like:
>>
>> variants:
>> - kvm_install:
>> cvs_server = "cvs.fedoraproject.org:/..."
>> type = kvm_install
>> mode = custom
>> install_command = "install_from_fedora_cvs.sh"
>> - everything_else_in_kvm_tests.cfg:
>> <tests>
>> ...
>> <guests>
>> ...
>> <smp/up>
>> ...
>> <ide/scsi/virtio_blk>
>> ...
>>
>
> We could have something to make it easier to build test runs like ,
> without having to nest the whole original file. But I can't think of a
> good solution.
>
>
>
>> variants:
>> - CVSF10:
>> kvm_install:
>> cvs_branch = F10
>> - CVSF11:
>> kvm_install:
>> cvs_branch = F11
>> - CVSRawhide:
>> kvm_install:
>> cvs_branch = devel
>>
>> # test sets
>> variants:
>> - nightly:
>> ...
>>
>> That is, assuming you want to
>> - install KVM from F10 branch
>> - run all tests
>> - install KVM from F11 branch
>> - run all tests
>> - install KVM from devel branch
>> - run all tests
>>
>> If you meant something different please correct me.
>>
>
> Yeah. I am not really used to the configuration file format, but that
> was the idea. :)
>
I've reworked the patch to use test.bindir and force it to run from
kvm_runtest_2. I also doubled checked that both parameters and
variables defined in the params object are available to the script. The
updated past should go out shortly.
Right now, nothing from the kvm_tests.cfg file is available. I don't
see an obvious way to do that, but we can put that into a separate patch
if needed later.
Mike
next prev parent reply other threads:[~2009-05-12 15:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <471764781.379441242067968821.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-05-11 19:00 ` [PATCH][KVM-AUTOTEST] Add custom install option for kvm_install Michael Goldish
2009-05-11 19:19 ` Eduardo Pereira Habkost
2009-05-12 15:28 ` Mike Burns [this message]
2009-05-13 7:12 ` Avi Kivity
2009-05-12 15:34 Mike Burns
2009-06-01 15:46 ` Uri Lublin
2009-06-01 18:25 ` Mike Burns
[not found] <1254147621.368741242063155059.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-05-11 17:36 ` Michael Goldish
2009-05-11 17:52 ` Mike Burns
2009-05-11 18:34 ` Eduardo Habkost
2009-05-11 18:43 ` Mike Burns
2009-05-11 18:30 ` Eduardo Habkost
-- strict thread matches above, loose matches on Subject: below --
2009-05-11 15:51 Mike Burns
2009-05-11 18:52 ` Lucas Meneghel Rodrigues
2009-05-08 18:55 Mike Burns
2009-05-11 13:49 ` Eduardo Habkost
2009-05-11 15:06 ` Mike Burns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A0995A0.8040302@redhat.com \
--to=mburns@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mgoldish@redhat.com \
--cc=ulublin@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox