RFC Fedora 23 Change idea

Stephen Gallagher sgallagh at redhat.com
Tue May 26 14:02:14 UTC 2015


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 at redhat.com> wrote:
> 
> > Dan Mossor <danofsatx at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20150526/1b1c7705/attachment.sig>


More information about the server mailing list