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

[ybronhei]

Hey all,
back from France

On 04/02/2014 11:29 AM, danken at redhat.com wrote:
> 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.
https://github.com/ficoos/cpopen/pull/23 <- committed 1.3 tag
https://pypi.python.org/pypi?:action=display&name=cpopen&version=1.3 <- 
uploaded latest code
>
>    - 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.
>      - 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.
>


-- 
Yaniv Bronhaim.