On 09/12/12 02:34pm, Chris Evich wrote:
>
> Thanks for the fix! Your reasoning sounds good to me. I have just
> two questions...
>
> On 09/12/2012 01:36 PM, Prem Karat wrote:
> >virsh freecell has libvirt=on& libvirt=off as the main variants and hence
> >evey test under freecell will include either on of them as the parameter.
> >Hence while preparing libvirt service for every test, this check can be
> >avoided.
> >
> > # Prepare libvirtd service
> > check_libvirtd = params.has_key("libvirtd")
> > if check_libvirtd:
> >
> >Params will always have either libvirtd as on or off as variants show
> >below in subtests.cfg.sample
> >
> > variants:
> > - libvirton:
> > libvirtd = "on"
> > - libvirtoff:
> > libvirtd = "off"
> > status_error = "yes"
> >
> >Cleaning up to avoid the unnecessary check and introducing a check to
> >see the status of libvirt daemon and if its not running, will start the
> >service on "libvirtd = on" variant.
>
> As much as I try to catch them in patches, it's conceivable that a
> prior virsh_* test had a problem and failed to recover libvirtd
> service. In this case, if virsh_freecell happens to be the
> following test, it may hide a bug or test problem. Assuming this is
> unlikely event, do you think it's worth worrying about?
What kind of problem are you referring here? Assuming Test Failures, that should
be captured by the individual tests.
I wouldn't worry about that because all we are trying to do is to ensure that
libvirtd service is running for any virsh_commands to execute.
>
> Second, if this patch is implemented. What do you think if I were
> to make it the "standard" by putting this libvirtd
> check/start/restart/stop stuff into a common place, like virt_env
> pre/post process?
>
> i.e. it seems nearly all the virsh_* tests are taking these same
> steps, it would be nice to have uniform behavior.
Yes I agree with that. Preparing libvirt during pre process and recovering post
process would be the ideal thing to have.
>
--
-prem
_______________________________________________
Autotest-kernel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/autotest-kernel
