On Wed, Dec 14, 2016 at 12:40:53PM +0530, Prasanna Kumar Kalever wrote: > On 16-12-14 07:43:05, Niels de Vos wrote: > > On Fri, Dec 09, 2016 at 11:28:52AM +0530, Prasanna Kalever wrote: > > > Hi all, > > > > > > As we know gluster block storage creation and maintanace is not simple > > > today, as it involves all the manual steps mentioned at [1] > > > To make this basic operations simple we would like to integrate the > > > block story with gluster CLI. > > > > > > As part of it, we would like Introduce the following commands > > > > > > # gluster block create <NAME> > > > # gluster block modify <SIZE> <AUTH> <ACCESS MODE> > > > # gluster block list > > > # gluster block delete <NAME> > > > > I am not sure why this needs to be done through the Gluster CLI. > > Creating a file on a (how to select?) volume, and then export that as a > > block device through tcmu-runner (iSCSI) seems more like a task similar > > to what libvirt does with VM images. > > May be not exactly, but similar > > > > > Would it not be more suitable to make this part of whatever tcmu admin > > tools are available? I assume tcmu needs to address this, with similar > > configuration options for LVM and other backends too. Building on top of > > that may give users of tcmu a better experience. > > s/tcmu/tcmu-runner/ > > I don't think there are separate tools/utils for tcmu-runner as of now. > Also currently we are using tcmu-runner to export the file in the > gluster volume as a iSCSI block device, in the future we may move to > qemu-tcmu (which does the same job of tcmu-runner, except it uses > qemu gluster driver) for benefits like snapshots ? One of the main objections I have, is that the CLI is currently very 'dumb'. Integrating with it to have it generate the tcmu-configuration as well as let the (current management only!) CLI create the disk-images on a volume seem breaking the current seperation of tasks. Integrations are good to have, but they should be done on the appropriate level. Teaching the CLI all it needs to know about tcmu-runner, including setting suitable permissions on the disk-image on a volume, access permissions for the iSCSI protocol and possibly more seems quite a lot of effort to me. I prefer to keep the CLI as simple as possible, and any integration should use the low-level tools (CLI, gfapi, ...) that are available. When we integrate tcmu-runner now, people will hopefully use it. That means it can not easily be replaced by an other project. qemu-tcmu would be an addition to the tcmu-integration, leaving a huge maintainance burdon. I have a strong preference to see any integrations done on a higher level. If there are no tcmu-runner tools (like targetcli?) to configure iSCSI backends and other options, it may make sense to start a new project dedicated to iSCSI access for Gluster. If no suitable projects exist, a gluster-block-utils project can be created. Management utilities also benefit from being written in languages other than C, a new project offers you many options there ;-) > Also configuring and running tcmu-runner on each node in the cluster > for multipathing is something not easy (take the case where we have > more than a dozen of node). If we can do these via gluster CLI with > one simple command from any node, we can configure and run tcmu-runner > on all the nodes. Right, sharing configurations between different servers is tricky. But you can also not assume that everyone can or want to run the iSCSI target on the Gluster storage servers themselves. For all other integrations that are similar, users like to have the flexibility to run the additional services (QEMU, Samba, NFS-Ganesha, ..) on seperate systems. > > If you can add such a consideration in the feature page, I'd appreciate > > it. Maybe other approaches have been discussed earlier as well? In that > > case, those approaches should probably be added too. > > Sure! Thanks! I hope I explained my opinion well, and you take it into consideration. Cheers, Niels > > -- > Prasanna > > > > > Thanks, > > Niels > > > > > > > > > > > > > [1] https://pkalever.wordpress.com/2016/06/23/gluster-solution-for-non-shared-persistent-storage-in-docker-container/ > > > > > > > > > Thanks, > > > -- > > > Prasanna > > > _______________________________________________ > > > Gluster-devel mailing list > > > Gluster-devel@xxxxxxxxxxx > > > http://www.gluster.org/mailman/listinfo/gluster-devel > >
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
