Re-unifying udisks and storaged

Mon Nov 28 15:04:07 UTC 2016

On Fri, 2016-11-25 at 15:32 +0100, Martin Pitt wrote:
> Hello storaged and udisks developers,
> 
> I spent some time on udisks life support today: mopping up some
> patches in bugzilla, fix failure with latest glib, and the like. Much
> of that affects storaged too (e. g. the glib test failure). But for
> the most part, udisks is vastly undermaintained, altough there is a
> high chance that I'll have more time for it from next year on.
> 
> But especially since the API and CLI of storaged got renamed back to
> "udisks" and it's now a drop-in replacement, I think we should end
> this forking and re-unify the projects again:

Hello everybody,

this is really great news and I cannot even express how much happy this
proposal makes me. It definitely makes sense to join the efforts and
focus on a single codebase instead of porting patches from one to another
and vice versa.

> 
>  * The current code base of storaged should become "the" official
>    project, and the old udisks 2.1.x should be mothballed after a
>    final merge of the recent fixes into storaged.
> 
>  * Personally I would prefer to leave development on GitHub, as it's
>    much more powerful than fd.o in terms of CI and much more nicely
>    integrated with issue reports.
I can only agree that GitHub is really nice for this. So definitely +1
from me here. The only exception is the public discussion already
mentioned by Tomas.

> 
>  * We can decide later whether we want to mass-close the fd.o bugs at
>    some point and ask people to re-submit issues against github if
>    their report is still current. ("bug bankrupcy" + migration to GH).
> 
>  * storaged PRs do run some tests, but unfortunately the result links
>    don't work at all so I don't know what they actually test. I would
>    hope that at least build + src/tests/integration-test? If not,
>    that's something I would like to work on/set up. E. g.
>    https://semaphoreci.com/ offers full QEMU (although only on Ubuntu
>    14.04, but it should suffice) which is enough to run the scsi_debug
>    tests. If that's already the case in the current tests, then ignore
>    me of course.
I'd like to apologize for this a bit. As Tomas has already mentioned, the
CI is running on our internal Red Hat machines and it's not particularly
easy to publish the results in some sane way. However, my plan for the
next two weeks is to use Stef's sink [1] tool to make this work much 
better.

[1] https://github.com/cockpit-project/cockpituous/tree/master/sink

We are currently running the src/tests/dbus-tests/* tests and the idea is
to cover the whole DBus API with such tests, focusing on the original
UDisks2 pieces first. The reason for primarily running these tests is that
we want to catch any regressions/changes in the DBus API caused by any
future changes ASAP.

But we can definitely enable the integration-tests as well.

> 
>  * At some point I should probably become a storaged project member,
>    but there is no urgency -- everyone including project members
>    should always use PRs anyway.
Indeed. As Tom has already mentioned, we are keeping the changes open for
review for some time to give people a chance to comment (and complain :).
I think all changes should go through this process. Of course, trivial
things can be merged right away without waiting, but at least second pair
of eyes should review them.

> 
> What do you think about this in general?
> 
> My instinct tells me that the hardest part of this will (as usually)
> be the naming: udisks or storaged. Quite a lot of upstream and
> third-party software builds/links against/calls the "udisks" API, and
> indeed storaged ships and provides just that, which is rather
> confusing. Even more curiously, Fedora builds a "libstoraged" package
> which ships libudisks.so.
> 
> So it seems that renaming "storaged" to "udisks" would be the simpler
> alternative as it would not require changes to external
> software/packages. If you prefer to keep "storaged", then I think it's
> better to rename the D-Bus API/library/ABI consistently and port the ~ 30
> users of it (at least that's how many we have in Debian) to the new
> names.
As Tomas has already explained, this is not a problem in Fedora. And to be
honest, I see storaged as a bit different project than udisks. Especially
when thinking about the goals. The plan for storaged is not to just be a 
"hey, disk appeared, do you want to mount it?" kind of daemon. And please
don't take me wrong here, I know udisks goes far beyond that even though
I'm still getting familiar with some parts of its codebase. Anyway, storaged
(esp. its extra modules) focuses on storage configuration management. As I
tried to explain in my blog post [2] I see storaged as a next evolution step
of udisks2. And changing the name to "storage daemon" makes perfect sense to
me under that light.

[2] http://www-rhstorage.rhcloud.com/blog/vpodzime/storaged-next-evolution-step-udisks2

So if that's possible and okay for people, can we consider the original
UDisks2 API provided an intermediate step to moving to a new API? We
definitely
want to add new things. And we would like to add them without
things like "all strings are actually byte arrays" which is inconsistent
with the UDisks2
API. With the intermediate solution we have right now we
have time to work with the users of the API and help them migrate to the
new one.

Just my two cents on this...

> 
> We mentioned this a while ago already in some private email exchange,
> but let's discuss it publicly on the ML now and actually reach a
> decision this time. :-)
Big THANKS for (re)starting this discussion. I'm eager to see the new ideas
and suggestions.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic