Evolving storaged API

Jan Safranek jsafrane at redhat.com
Tue Jan 28 08:54:56 UTC 2014


On 01/28/2014 09:13 AM, Marius Vollmer wrote:
> Hi,
> 
> the dependency of storaged on UDisks is itching me a bit.  It should
> work very well with it, but I think it should also work without it, I'd
> say.
> 
> We are not far away from that goal, actually.  Here is what I have in
> mind...
> 
> - Add "Device" property to LogicalVolume.  Then clients can work with
>   logical volumes without UDisks.
> 
> - Add PhysicalVolume objects, with "Device" etc properties and "Remove"
>   etc methods.  Make PhysicalVolumeBlock point to it instead of the
>   VolumeGroup.
> 
> - Change VolumeGroupCreate and AddDevice methods to take /dev/foo
>   devices instead of UDisks object paths.
> 
> - Add VolumeGroupCreateFromUDisksPath etc.
> 
> - Add UdisksBlock properties to LogicalVolume and PhysicalVolume that
>   point to the UDisks objects.
> 
> - Have our own Job interface.
> 
> - Just watch whether UDisks is running, but don't start it.
> 
> What do you think?


Just a question, will it still be possible to _easily_ match UDdisks
object with storaged objects? Now they have the same object path, will
it stay the same? I find it pretty convenient from application point of
view.


Jan


More information about the cockpit-devel mailing list