On 12/21/2016 09:15 PM, Prasanna Kalever wrote:
[Top posting]
I agree with Niels and Shyam here. We are now trying to decouple the
gluster-block cli from gluster cli.
Since anyway it doesn't depend on core gluster changes, I think its
better to move it out. Also I do not see a decent tool/util that does
these jobs, hence its better we make it as a separate project (may be
gluster-block).
The design side changes are still in discussion, I shall give an
update once we conclude on it.
Since gluster-block plans to maintain it as separate project, I don't
think we still need to make it as 3.10 feature.
With gluster-block we will aim to support all possible versions of gluster.
Should this be bundled with gluster? If so, it maybe a good thing to
track that part against gluster releases (3.10 or otherwise). Just a
thought.
Thanks,
--
Prasanna
On Mon, Dec 19, 2016 at 5:10 PM, Shyam <srangana@xxxxxxxxxx> wrote:
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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
