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

- 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 and REST binding, with which C/whatever clients can

- 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

- probably more stuff that I've forgotten... please reply with more info

See ya all!

vdsm-devel mailing list

Reply via email to