Re-unifying udisks and storaged

[Vratislav Podzimek]

On Mon, 2016-11-28 at 22:17 +0100, Martin Pitt wrote:
> Hello Vratislav,
> 
> Vratislav Podzimek [2016-11-28 16:04 +0100]:
> > >  * 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.
> 
> Please don't apologize for having CI! :-) Things can always be
> improved of course. I was mostly just wondering what actually runs
> there.
> 
> That said, I'm a big believer in making such integration tests
> reproducible and available to every developer, as otherwise they will
> be hard to maintain and the onus of keeping them up to date will
> always lie with the core developers instead of PRs and contributors.
> But it seems this is already in progress:
> 
> > 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.
> 
> Great to hear!
> 
> > 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.
> 
> Yes, understood. Due to its modules it will continue to remain
> possible to not ship the "enterprise-y" features in a desktop install
> to avoid extra dependencies; do you plan on keeping this?
Sure, we want to keep it modular as much as possible. There are definitely
environments that we want to support/cover which don't need any of these extra
features.

> 
> So, as I said I'm not fundamentally opposing the "storaged" name, and
> æsthetically it's quite nice too. I'm just saying that we shouldn't
> keep a project name "storaged" and not ship a single "storaged"
> binary/CLI/D-Bus name in it, as that's rather confusing. In other
> words, if we go with "storaged" it should be done consistently.
Absolutely agreed and I think that should be our (long-term) goal.

Thanks!

-- 
Vratislav Podzimek

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