Hello. I'm one of the people who are involved in the storaged [0] project. It's an udisks2 fork created originally for Cockpit [1] and OpenLMI [2]. I understand many people see the fork as hostile move and ask us why couldn't we just contribute to udisks2. Last time this question appeared on Dominik Perpeet's blogpost about building Cockpit for Debian [3]. I have been asked to copy my answer here so the udisks2 people can get the chance to respond eventually, and we would like to express our will to join forces again if there was an interest.
There were several projects trying to use udisks for non-desktop storage management in the past. The people behind storaged come from the (now discontinued) OpenLMI project---it was another remote system management API attempt---and at the time we started with storage module we reached out to the udisks upstream (David Zeuthen) and talked about our needs and what would we want from udisks. David's stance was quite firm on this: udisks was to be focused on desktop use-cases and any "enterprise" feature (LVM was the most painful one...) was considered to be unnecessary bloat making the code harder to maintain. We respected (and understood) that position, however we needed to solve our problem with missing storage API. OpenLMI has then decided to build on Blivet (Fedora/RHEL library created for the Anaconda installer) which was AFAIK another project launched because udisks upstream was not willing to accept some features and it happened even long before OpenLMI. Blivet was however tailored to the installer requirements and not that good for generic storage management. So OpenLMI had to find some other API. And in parallel, there came Cockpit facing the same problem. Cockpit was originally built with udisks2 as a backend and another daemon that complemented udisks2 adding LVM support. (It was called storaged.) However this scheme with two daemons was causing problems and since the split was made for mostly "political" reasons, we decided to give up and merge the LVM code into udisks2 ourselves and continue developing one universal daemon/API. And again: there were attempts to convince udisks2 upstream to accept the LVM code prior the decision: the fork was actually even suggested by udisks upstream (https://bugs.freedesktop.org/show_bug.cgi?id=68609). I admit that many of the conversations happened in person and by e-mails, so it's not that easy to find out. If udisks2 upstream would be willing to support the server-type use cases, we would of course gladly join them. But again: it's already many years old topic. And unless udisks2 upstream changes their mind, there is no other option than to continue with storaged. Regards, -- Tomáš Smetana [0] http://storaged-project.github.io/ [1] http://www.openlmi.org/ [2] http://cockpit-project.org/ [3] http://dominik.perpeet.eu/cockpit-on-debian-8-2 _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
