[Gluster-devel] Release 3.10 feature proposal : Gluster Block Storage CLI Integration

[Shyam]

On 12/14/2016 01:38 PM, Niels de Vos wrote:
> 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.

+1, I agree. This seems more like a task for a tool using gfapi in parts 
for the file creation and other CLI/deploy options for managing 
tcmu-runner. The latter a more tcmu project, or gluster-block as the 
abstraction if we want to gain eyeballs into the support.

>
> 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!

We may be missing something, so beefing up the feature page would 
possibly help understand the gaps. As of now adding these to the gluster 
CLI seems like the incorrect place to integrate this capacity.

>
> 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 at gluster.org
>>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>>
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel