Today we did have a meeting, and discussed the following points:
- We need a volunteer to extend vdsm's on-commit hook, so it runs functional
tests to. This requires installing vdsm.rpm as well as vdsm-tests.rpm,
starting vdsmd service, running the tests, and cleaning the host.
Robert M. suggested that we ask infra@ for help in writing and maintaining
this test, so here I am, CCing infra(a)ovirt.org.
- Saggi is planning a C API library, exposing gobjects, with a rest bridge (or
whatever) for client applications. I'm slightly appauled - I prefered the
simpler idea of API.py and REST binding, with which C/whatever clients can
interact.
- Adam documented the current xmlrpc api, with all its pecularities and
horrors. Prefers to keep it as a single document; I think it would be
easier to maintain if definition that are specific to an API call sit
on top the function definition. It would be harder to forget to update
one of them when you change the other. Admitedly, it requires some sed
preprocessing in order to extract a single human-readable document out
of this scattered info. Saggi votes for Adam.
- deepakcs: i just posted VDSM hook example for exploiting native
qemu-glusterfs options from VDSM. Wanted to know feedback onthe same and
alternative approach
- Saggi asks to ping qemu folks about the feature of specifying the full
qcow chain BZ#750801. We need it to reduce repository complexity
(currently we play with symlinks).
- Federico: storage domain v 3 , requires bleeding-edge upstream engine and
sanlock.
http://wiki.ovirt.org/wiki/Storage_Domain_Versions
- probably more stuff that I've forgotten... please reply with more info
See ya all!
Dan.