[vdsm] vdsm sync meeting minutes April 1st, 2014

Antoni Segura Puimedon asegurap at redhat.com
Wed Apr 2 08:35:35 UTC 2014



----- Original Message -----
> From: danken at redhat.com
> To: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, devel at 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 devel at 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 at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 


More information about the vdsm-devel mailing list