UDisks LVM addon ready to play with - cockpit-devel - Fedora mailing-lists

19 Dec 2013


      So after some work on udisks-lvm it's now ready to play with. Lots has
changed in the implementation, and a few things have changed in the DBus
interfaces that were proposed in the patches.
Note that the DBus interfaces have the prefix of com.redhat.lvm2. Happy
to change this early on, if it's not acceptable.
Code, as before is here: https://github.com/stefwalter/udisks-lvm
Now accepting patches :)
Implementation notes follow ...
Testing:
Basic functionality is tested. But I didn't have time to complete tests
for everything for the initial block of code. I think for each change
that we do from here on out we should try and make sure it's covered by
a test.
HACKING contains info on how to run the tests in a VM, using NFS to
access the built files, and (if rw mounted) write test coverage data back.
No client API:
No client interface (yet?). Since OpenLMI wants to use DBus directly,
and I imagine Cockpit can have it's own client interface.
DBus interface file is installed into /usr/share/dbus-1/interfaces as
you would expect. Easy to gdbus-codegen a client API from there if one
wants to go that route.
Simple Object Manager:
Made the object manager usage *much* simpler. We avoid object skeletons,
and have a high level concept of publishing interfaces or objects.
Waiting for objects to show up is also streamlined. We rely on DBus
timeouts when they don't show up, rather than inventing our own timeouts.
Threading:
No use of threading in method handlers. The previous code was not thread
safe in several areas. Things like polkit authorization and caller uid
lookup happen before the method handler.
Some of the previous jobs didn't actually encapsulate the whole task,
especially where we were wiping blocks. These are now wrapped into
threaded jobs. Very careful to pass only copied fundamental types, such
as strings and flags into these threaded jobs.
Authorization
Handle polkit authorization in g-authorize-method signal as one would
expect. We load the authorization info from annotations in the DBus
interface, rather than all over.
Do the actions may need to be more segmented? Currently we just have one
com.redhat.lvm2.manage-lvm action.
Daemon shutdown:
The daemon quits when all its clients are gone, and no jobs are running.
Since we want to use this on the server, it really makes sense not to
have yet another daemon running all the time.
Colin, if you have time I would appreciate your feedback on the lifetime
implementation. I've tried to do this in a non-racy manner, enabled by
the fact that our daemon is rather stateless.
LVM name encoding
The Name property now contains the possibly encoded name, and the
DisplayName the possibly decoded one.
That said I don't think we should be encoding the LVM volume group and
logical volume names passed in over the DBus API. This goes against the
Cockpit ethos (and likely OpenLMI too) of exposing what's on the
system rather than hiding it away under some layer. Encoding the   names
makes it awkward to create a volume group via the API and then use it
from the command line.
Poll()
Do we really need to have Poll()? Can we just poll as needed, especially
now that we quit when no more clients are around?
Cheers,
Stef