----- Original Message ----- > From: dan...@redhat.com > To: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>, > de...@ovirt.org > Sent: Wednesday, April 2, 2014 10:29:09 AM > Subject: [vdsm] vdsm sync meeting minutes April 1st, 2014 > > Vdsm sync call April 1st 2014 > ============================= > > - cpopen: > - Toni: there's a versioning mismatch: the version in pypi is higher > than the one on https://github.com/ficoos/cpopen > - Saggi: there shouldn't be any code difference > - Yaniv should sync the two. > > - We use two options that are missing from Python3's Popen: umask and > deathSignal. > - Toni to re-send his Python3 port for cpopen, with tests running on > Python3, too. https://github.com/celebdor/cpopen/commit/6db0429de06020c2c62007f6d1a3b41906e85742
I did it last night. There's still the noclosefds test failing for unknown reasons. I'll investigate it. > - Saggi to accept it. > - Infra team to suggest missing features to Python. > > - fromani described his attempts of consolidating the two > migration-monitoring threads into one. The motivation is a finer way > of contolling the migration down time based on progress. Reducing > thread numbers per se is not the main motivation. > > - pep8 has changed. Again. Version 1.5.1 has even more draconic > requirements. We can comply with them, or, include our version of > pep8/pyflakes/pylint in our git repo. danken shudders at the thought > of copying the code, but having a git sub-module is a reasonable > compromise. > - Infra team to take this task (unless someone else is faster) > - Until that happens, one need to use pep8-1.4.6 or --ignore offending > errors. > > - We've been asked to kill the separate vdsm-devel mailing list, and > join it into de...@ovirt.org. There's some resistence in the audience, > so we'd do it softly. > > Next week, I'll have vdsm-devel members mass-subscribed to > devel@ovirt. If you do NOT want to be subscribed, please send me a > private request. > > Then, for several months, we'd see how it goes, and whether we drown > in unrelated Engine chatter. > > - We had a very (too) heated debate about ignoring failures of > setDomainRegularRole() in http://gerrit.ovirt.org/24495/ and > http://gerrit.ovirt.org/25424. > > 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. > > Dan. > _______________________________________________ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
