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
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to