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