On Tue, Apr 08, 2014 at 06:52:50AM -0400, Francesco Romani wrote:
> Hello VDSM developers,
Please use devel@ovirt, and mention "vdsm" at the subject. This thread
in particular involves Engine as well.
> I'd like to discuss and explain the plans for cleaning up Vm.getStats()
> in vdsm/virt/vm.py, and how it affects a bug we have: https://bugzilla.redhat.com/show_bug.cgi?id=1073478
> Let's start from the bug.
> To make a long story short, there is a (small) race in VDSM, probably introduced by commit
> The race can actually be triggered only if the VM is shutting down, so it is not that bad.
> Fixing the reported issue in the specific case can be done with a trivial if, and that it what I did
> in my initial http://gerrit.ovirt.org/#/c/25803/1/vdsm/vm.py,cm
Could you explain how an AttributeError there moved the VM to Down?
> However, this is just a bandaid and a proper solution is needed. This is the reason why
> the following versions of http://gerrit.ovirt.org/#/c/25803 changed direction toward a more comprehensive
> And this is the core of the issue.
> My initial idea is to either return success and a complete, well formed statistics set, or return an error.
> However current engine seems to not cope properly with this, and we cannot break backward compatibility.
Would you be more precise? If getAllVmStats returns an errCode for one
of the Vms, what happens?
> Looks like the only way to go is to always return success and to add a field to describe the content of the
> statistics (partial, complete...). THis is admittedly a far cry from the ideal solution, but it is dictated
> by the need to preserve the compatibility with current/old engines.
I don't think that I understand your suggestion, but it does not sound
right to send a partial dictionary and to "appologize" about its
paritiality elsewhere. The dictionary may be "partial" for engine-4.0
yet "complete" for engine-3.5. It's not for Vdsm to grade its own
> Moreover, I would like to take the chance and cleanup/refactor the statistics collection. I already started
> adding the test infrastructure: http://gerrit.ovirt.org/#/c/26536/
> To summarize, what I suggest to do is:
> * fix https://bugzilla.redhat.com/show_bug.cgi?id=1073478 using a simple ugly fix like the original
> http://gerrit.ovirt.org/#/c/25803/1/vdsm/vm.py,cm (which I'll resubmit as new change)
> * refactor and clean getStats() and friends
> * on the cleaner base, properly fix the statistics collection by let getStats() always succeed and return
> possibly partial stats, with a new field describing the content
> please note that I'm not really happy about this solution, but, given the constraint, I don't see better
Please explain the benefits of describing the partial content, as I do
not see them.
I'm in the process of evaluating RFEs for 3.5.0. I want to be able to push RFEs to next release, can anyone please create a 3.6.0 target release?
BI Software Engineer
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
IRC : Yaniv D
On 04/03/2014 07:51 PM, Liran Zelkha wrote:
> The problem is with both updates and selects.
> For selects - to get all the information for the VDS we have multiple
> joins. Adding another one will hurt performance even more.
> For updates - we have vds_static thats hardly changed. vds_statistics
> that changes all the time. vds_dynamic is not changed allot - but is
> updated all the time because of the status. I think it's best to split
> it to the two existing tables (BTW - relevant for VM as well)
but we don't update it unless the status has changed, which is a rare
As you should know, we released oVirt 3.3.5 yesterday.
After this release, only security fixes will be allowed on 3.3 branch and only a security update will cause a new oVirt 3.3.z release.
It's time to focus on new features for 3.5.0!
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
----- Original Message -----
> From: "Dan Kenigsberg" <danken(a)redhat.com>
> To: devel(a)ovirt.org
> Cc: vdsm-devel(a)ovirt.org, vered(a)redhat.com, fromani(a)redhat.com
> Sent: Thursday, April 3, 2014 6:08:31 PM
> Subject: [Devel] Vdsm functional tests
> Functional tests are intended to verify that a running Vdsm instance
> does what it should, when treated as a black box, over its public API.
> They should be comprehensive and representative of a typical field usage
> of Vdsm. It is a sin to break such a test - but we must be able to know
> when such a sin is committed.
> We currently have the following functional tests modules:
> - sosPluginTests.py
> - storageTests.py
Storage localfs will be good to go by May 8th.
> - momTests.py
> - networkTests.py
> I'd like to have a designated developer per team (infra, storage, virt and
> network), responsible to having these tests ever-running.
> When could we expect to have it running per commit on a Jenkins slaves?
> Volunteers, please come forward.
> Devel mailing list
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> To: "Brian Proffitt" <bproffit(a)redhat.com>
> Cc: "arch" <arch(a)ovirt.org>
> Sent: Friday, April 4, 2014 7:31:56 PM
> Subject: Re: Attention: Mailing List Change
> ----- Original Message -----
> > From: "Brian Proffitt" <bproffit(a)redhat.com>
> > To: "arch" <arch(a)ovirt.org>
> > Sent: Wednesday, March 26, 2014 8:39:51 PM
> > Subject: Attention: Mailing List Change
> > All:
> > One of the long-standing requests in the oVirt community is the merging of
> > the [arch] and [engine-devel] mailing lists. This note is an announcement
> > that on Monday, March 31, this will get done.
> > What will happen:
> > 1) Subscribers from [arch] and [engine-devel] will be migrated to a new
> > [devel] list.
> > 2) Archives from [arch] (this list) will be left as is, and available for
> > searching on the list.ovirt.org/mailman site.
> > 3) Archived from [engine-devel] will be renamed to [devel]
Can we rename [devel] prefix to [ovirt-devel], it is confusing with other
Same I guess to any ovirt list.
> > If you have any comments or concerns, let me know.
> > Thank you for your patience in this matter,
> > Brian
> > --
> > Brian Proffitt - oVirt Community Manager
> > Open Source and Standards, Red Hat - http://community.redhat.com
> > Phone: +1 574 383 9BKP
> > IRC: bkp @ OFTC
> > _______________________________________________
> > Arch mailing list
> > Arch(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
On Wed, Apr 02, 2014 at 09:29:09AM +0100, danken(a)redhat.com wrote:
> - We had a very (too) heated debate about ignoring failures of
> setDomainRegularRole() in http://gerrit.ovirt.org/24495/ and
> The pain point is that relying on domain role (master/regular) is
> faulty by design. We cannot avoid the cases where a pool has more than
> one domain with a master role written in its metadata.
> One side argued that oVirt should be fixed to handle this unescapable
> truth, or at least enumerate the places where Vdsm and Engine, both
> current and old, depend on master role uniqueness.
> The other side argued that this is not a priority task, and that we
> should try to "garbage-collect" known-bad master roles as a courtesy
> to people digging into domain metadata, and as a means to lessen the
> problem until we kill the pool concept in the upcoming version.
> I hope that I present the debate fairly enough.
In order to move these two patches forward, how about:
- Limit the usage of the catching-all "except Exception" and replace
it with swalling only the expected IO error
- Add a comment about setDomainRegularRole() being called only as a
courtesy garbage-collection attempt.
- Conduct a survey on whether migrateMaster is used by anyone. No
supported Engine has it, but I there was a suggestion that it was
still expected via the command line.
What do you think?