On Tue, 2015-05-26 at 10:44 +0200, Tomáš Smetana wrote:
On Tue, 26 May 2015 10:03:23 +0300
Marius Vollmer <marius.vollmer(a)redhat.com> wrote:
> Dan Mossor <danofsatx(a)gmail.com> writes:
>
> > To make this as flexible as possible, I feel we still need a good
> > WebUI for Samba, as well as NFS and iSCSI. FreeNAS has done an
> > awesome
> > job on their interface that provides all of these options, I
> > wonder if
> > we can use any of their code in Cockpit, at the very least for
> > inspiration.
>
> Interesting! Storage-wise Cockpit is moving from UDisks2 to
> storaged as
> the backend. Storaged is a fork of UDisks2 and is rapidly
> acquiring new
> features like iSCSI, LVM2, and support for libstoragemgmt. Network
> filesystems would be a good fit but I don't know whether anybody is
> working on that already.
>
>
http://storaged-project.github.io/
Hi.
I'm pretty sure nobody works on anything Samba or NFS related in
storaged.
And we can only configure the iSCSI initiator which is not that
interesting
for the NAS use-case. Speaking of the proposed idea (NAS
configuration UI).
I wonder if that would really be a good fit for the storaged API. So
far we
were dealing with the storage devices, filesystems, etc. This would
broaden
the scope to a storage services management too. We have not really
considered that (yet...).
I think the umbrella of the storaged project would be a good place to
build up these APIs, if only to be able to capitalize on the wide
domain knowledge of the other developers on that project.
I can imagine that Samba configuration management would be quite
demanded
feature. However Samba is much more than just a file sharing service
and I'm
not sure we would be able to simply isolate that one piece from it.
So we may
need special APIs for Samba for example.
We certainly do need to write an API to manage SMB, but I think it's a
lot simpler to do than one might think. We don't necessarily need to
isolate everything, we just need to modify the smb.conf file and reload
the daemon.
NFS server and iSCSI target might be
simpler but again: it's more services configuration than storage.
Sure, but given all the success you've managed in converging into a
single set of APIs, it seems counterproductive to attempt to build this
elsewhere, to me.