vdsm sync meeting minutes April 1st, 2014

[Dan Kenigsberg]

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.
    - 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(a)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.

----- Original Message -----
>  From: danken(a)redhat.com
>  To: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org&gt;,
> devel(a)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/6db0429de06020c2c62007f6d1a3b41...

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(a)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(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>

Hey all,
back from France

On 04/02/2014 11:29 AM, danken(a)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(a)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.
>  

-- 
Yaniv Bronhaim.

[Dan Kenigsberg]

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
>    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. 
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?

[Federico Simoncelli]

----- Original Message -----
>  From: "Dan Kenigsberg" <danken(a)redhat.com&gt;
>  To: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org&gt;,
> devel(a)ovirt.org, laravot(a)redhat.com,
>  nsoffer(a)redhat.com, fsimonce(a)redhat.com
>  Cc: lyarwood(a)redhat.com
>  Sent: Wednesday, April 9, 2014 3:01:31 PM
>  Subject: Re: [vdsm] vdsm sync meeting minutes April 1st, 2014
>  
>  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
>  >   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.
>  
>  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. 
You don't call masterMigrate directly. It's triggered when you deactivate
the master domain.

-- 
Federico