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 in...@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. _______________________________________________ vdsm-devel mailing list firstname.lastname@example.org https://fedorahosted.org/mailman/listinfo/vdsm-devel