Speaking attendees (no particular order): Dustin, Saggi, Adam, Ayal,
Toni, Federico, Danken.

Issues raised:
- Danken thanks Adam for pulling active developers from Beijing to
  #v...@irc.freenode.net . It is fun to chat on irc, it's quick, and may
  be fruitful. So please autoconnect to #vdsm when you turn your desktop

- ovirt-3.2 release: nothing urgent, appart of a NetworkManager
  integration issue (see bellow). If there is a show stopper, please
  rebase to the ovirt-3.2 branch, and ping Federico.

- When adding a VM network on top of a bond device, we take the relevant
  devices down, we write their new ifcfg-* files (with
  NM_CONTROLLED=no), and take them up again.
  At this point, NM notices that the devices are no longer under its
  management, and takes them down asynchronously. See
  https://bugzilla.redhat.com/879180 .
  This race may force us to turn NM off on installation, but we'd rather
  have a finer-grain work-around. Pavel, maybe you can help us here.

- Task framework: we've spend a lot of time discussing with Saggi what a
  task framework should not be. According to Saggi, Engine can never
  expect to know that a task has finished, since it may loose
  connection to the host running it. Thus, in the worst case, Engine has
  to be able to poll for whatever entity was created/destroyed by that
  task. Saggi suggests to make this worst case the only case.

  He prefer to keep the current situation, where we have different verbs
  to create and poll for vm creation, start and poll migration
  progression, etc, and extend it to gluster tasks and storage image
  creation/deletion/copying tasks.

  To me it seems that an end user would benefit of having a unified view
  of what is currently going on in vdsm, how it progresses, and whether
  it can be stopped. However, this can be wrapped up nicely within the
  client with no abstraction in Vdsm.

I may have well lost part of the discussion, so please correct me on
list I I misrepresented an opinion.

vdsm-devel mailing list

Reply via email to