On Tue, Feb 2, 2016 at 6:19 PM, Dan Kenigsberg <danken@redhat.com> wrote:
(nir, piotr, danken)
- splitting supervdsmServer: I think that its a good idea, and that https://gerrit.ovirt.org/#/c/52875/ is a good start. It would give a nice separation of responsibility, and may serve as a "teaser" for how Vdsm's public API can be broken apart.
Nir is worried that it would introduce instability for no immediate gain, while distracting us from solving the supervdsmServer memory leak, or possible security concens
Or other stuff like porting to python 3. I'll leave the decision about this to Piotr.
- schema conversion: Piotr presented his https://gerrit.ovirt.org/#/c/52864/ which would convert the json-based schema into a cleaner yaml-based one, which would be easier to version, validate, and obsolete.
- Nir was unhappy with recent changes to the contrib client: https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:js... would prefer using standard stomp client
I'm ok, with switching to our jsonrpc library. I'm not happy about the additional changes - the client was kind of rewritten from scratch.
- name discussion is stalling. some people are worried that a rename may turn out to be expensive (release engineering, outher packages, interal module and function name). Still, it would be fun to foresake the non-pronounceable name "vdsm". ovirt-hostd seems like a front runner at the moment.
We also discussed the username - if we change the project name and the executables we probably want to change the vdsm user to something else (ovirt?). This may be a problem with existing file storage, using vdsm:kvm. I would like to avoid such changes.
- Nir has advocated trying to use https://trello.com/b/U3lsbVRU/maintenance to maintain the list of our pending tasks. Let's try.
Ciao! _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel