storaged: why did we fork udisks2

[Tomáš Smetana]

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