[Users] ovirt test day: HA VM Reservation feature test summary

[Doron Fediuck]

----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "users" <users at ovirt.org>
> Sent: Monday, February 3, 2014 1:17:38 PM
> Subject: Re: [Users] ovirt test day: HA VM Reservation feature test summary
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>
> > Cc: "users" <users at ovirt.org>
> > Sent: Monday, February 3, 2014 1:07:37 PM
> > Subject: Re: [Users] ovirt test day: HA VM Reservation feature test summary
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Moti Asayag" <masayag at redhat.com>
> > > To: "users" <users at ovirt.org>
> > > Sent: Monday, January 27, 2014 5:54:22 PM
> > > Subject: [Users] ovirt test day: HA VM Reservation feature test summary
> > > 
> > > Hi All,
> > > 
> > > In the latest ovirt-test-day i've tested the HA VM resource reservation
> > > feature [1] according to the basic scenarios as described on [2].
> > > 
> > > The new feature notifies the admin via an event log about his cluster
> > > inability to preserve resources for HA VMs. I've reported 2 bugs based
> > > on the behavior: The cluster check doesn't consider the state of the
> > > cluster's hosts when it calculates the resources [3] and a minor issue
> > > of the audit log translation into a message [4].
> > > 
> > > [1] http://www.ovirt.org/Features/HA_VM_reservation
> > > [2] http://www.ovirt.org/OVirt_3.4_TestDay#SLA
> > > [3] Bug 1057579 -        HA Vm reservation check ignores host status
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1057579
> > > [4] Bug 1057584 -        HA Vm reservation event log is not well resolved
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1057584
> > > 
> > > Thanks,
> > > Moti
> > 
> > Thanks, Moti.
> > Good catches. When looking at the code I also noticed 'none' policy does
> > not
> > use
> > the ha reservations weight module. Were you using the default policy or
> > something
> > else?
> > 
> 
> I used the the default ('None') policy in my testing.
> 

So indeed we may have another issue.

Thanks again,
Doron