Re: [Gluster-devel] RPM re-structuring

[Niels de Vos]

On Mon, Aug 05, 2013 at 03:12:31PM +0530, Deepak C Shetty wrote:
> On 08/05/2013 02:41 PM, Niels de Vos wrote:
> >On Mon, Aug 05, 2013 at 10:59:32AM +0530, Deepak C Shetty wrote:
> >>I am a bit lost here.. so pardon me if I am misquoting something.
> >>But I really wanted to know where does /usr/sbin/gluster sits, i
> >>mean which RPM ?
> >>
> >>Currently VDSM needs /usr/sbin/gluster since thats needed by gluster
> >>cli plugin of VDSM.
> >>This gluster plugin gets used to query the transport type as part of
> >>GLUSTERFS_DOMAIN storage domain usecase.
> >>
> >>Currently, this is what i see...
> >>
> >>rpm -qf /usr/sbin/gluster
> >>glusterfs-server-3.4.0beta1-1.fc17.x86_64
> >>
> >>which means for somebody to use gluster vdsm plugin, one needs to
> >>install glusterfs-server rpm.
> >>
> >>But from VDSM spec file...
> >>
> >>%if 0%{?with_gluster}
> >>%package gluster
> >>Summary:        Gluster Plugin for VDSM
> >>BuildArch:      noarch
> >>
> >>Requires: %{name} = %{version}-%{release}
> >>Requires: glusterfs >= 3.4.0
> >>Requires: glusterfs-server
> >>Requires: glusterfs-fuse
> >>Requires: glusterfs-rdma
> >>Requires: python-magic
> >>
> >>which means, that if the hypervisor host is not a gluster node,
> >>vdsm-gluster RPM is optional
> >>and if User doesn't install it.. he won't get glusterfs-server, and
> >>hence no /usr/sbin/gluster
> >This is indeed correct. Currently the glusterfs-server package contains
> >the 'gluster' binary. I think there are use-cases where this cli can be
> >used on systems that are not storage servers themselves (no
> >glusterfs-server package, no glusterfsd processes).
> >
> >In order to assist with this use-case, the 'gluster' cli binary could
> >be:
> >
> >a. moved to the main 'glusterfs' package
> >b. placed in a glusterfs-cli package (-server requires -cli)
> >
> >If solution a is selected, users that have only the glusterfs (and -api
> >or similar) installed might be confused about the useless 'gluster'
> >binary. Therefor my preference goes to creating a -cli package that
> >contains the binary (and man-page) only.
> 
> IIUC, per the prev threads.. glusterfs package has a dep on
> glusterfs-libs and in a typical
> hyp. only host environment (eg. VDSM) we need the glusterfs-libs
> (for qemu libgfapi) and gluster
> binary (for VDSM to query volume info as part of GLUSTERFS_DOMAIN).
> So option 'a' seems good to me,
> in the sense that one pkg install and User gets all the needed stuff
> for hyp. only host usecase.
> 
> Also the 'gluster' binary as-is is not useless. Are you saying so
> because the hyp. only host isn't a gluster peer ?
> 
> For eg: VDSM uses 'gluster volume info --remote-host=<ip/hostname of
> gluster node>' (works in both hyp. only host and gluster peer cases)
> so not sure why you say its useless ?

Yes, I understand that the binary is not useless in your case, and 
neither for the Object Storage environments. However, the --remote-host 
option is not commonly used by users on the commandline. Because 
standard usage will mainly result in errors (being 
--remote-host=localhost the default, and no listening process without 
glusterfs-server), I think not providing the binary together with the 
libraries is more user friendly.

HTH,
Niels