[ovirt-devel] vdsm sync meeting minutes May 13, 2014

[danken at redhat.com]

Vdsm sync call May 13, 2014
===========================
(Join us every other week, 14:30 GMT, on https://bluejeans.com/35386075901 or
https://www.intercallonline.com/listNumbersByCode.action?confCode=35386075901
)
===========================

- We had a long descussion about multiple graphic devices
  http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:graph_dev,n,z
  - fromani to figure out whether libvirt intends to provide an "alias" for
    graphics devices. Without it, it would be next-to-impossible to support
    multiple spice devices. It's already cumbersome to tell spice from vnc
    devices.
  - On input, Vdsm must accept both legacy display definitions (in vm.conf) and
    new-style ones (in vm.conf['devices']). If both exist, legacy ones are to
    be ignored.

- writeable floppies. We believe that they were never used. Currently, vdsm
  makes floppies writable based on the writability of their filesystem imagea,
  and checks it in an unsafe manner. So we intend to make all floppies
  read-only.

  Actually, it would be nicer to expose a "readonly" flag, so that
  the client can use in case it really needs to write on the floppy (such as
  for saving Doom I game state).

- live merge
  Saggi to review Adam's patches, and see if their use of task id is acceptable
  to him, and would follow the devel at ovirt.org thread on the matter.
  I'm still worried about Engine trusting the vdsm mapping of taskid to
  (vmid,volumeid), as Vdsm can crash and disappear.

- unified network persistence.
  recently, unified persistence has become the default on the master branch
  http://gerrit.ovirt.org/25784 this may cause breakage to post-boot network
  connectivity, in case vdsm fails to start.

  - To avoid this fragility, we plan to have a leaner standalone service to
    configure networking on boot.

  - As a stopgap measure, the management network would be set as ONBOOT=yes, so
    that most setup would keep their connectivity.

  please report other problems!

- ioprocess integration
  There's a worry regarding the path of replacing remote-file-handler with
  ioprocess. Currently, ioprocess is mimicking rfh semantics, while it is more
  reasonable to align with the future, and make the current rfh implementation
  mimick ioprocess.

  When network decided to move away from ifcfg to iproute2, we refactor the
  code to support both (with configurators), implemented iproute2, and only
  recently - moved to use it by default. This path ensures that we're not stuck
  with a convoluted code that matches no implementation.

Have I forgotten anything?

Dan.