Speaking attendees (no particular order): Dustin, Saggi, Adam, Ayal,
Toni, Federico, Danken.
- 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
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
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