On Thu, Jun 25, 2015 at 1:22 PM, Kaushal M <kshlmster@xxxxxxxxx> wrote:
> One other design characteristic I can think of is to have GlusterD-2.0
> be able to make best use of Nodes based on the Node topology, not sure
> if this is covered by any other feature below ?
>
> IOW, admin should be able to provide a hierarchy of how nodes are
> provisioned
> (rack, site, zone, region, geo etc) and glusterd should use this info while
> provisioning bricks for volume creation
>
The intelligent volume creation support that I mention later is nearly
this, without the additional markers of rack, site etc. For an initial
implementation, all we wanted was a way list available space, without
any special markers, and use this list to create volumes.
The design characteristics I wrote about, are mainly with respect to
how we want the internal frameworks for GlusterD-2.0 to be. These
frameworks will be the ones which will be used to implement other
feature requirements, like volume creation.
IMHO i feel this should be a design char as in "Node Topology Awareness"
I know this can be implemented on top of glusterd, but having this as part
of the design ensures we don't do something that won't be then extensible
as needed for glusterd to be topology aware.
> I have 2 things to say here :
>
> 1) Manila uses GlusterFS SSL auth mode, so is there any discussion happening
> around adding support in GlusterD-2.0 for managing SSL certificates ?
>
> For eg: Other (eg Netapp) storage arrays do provide basic digital cert mgmt
> support for server and client auth.
>
> I feel it would be good to have glusterd provide support to generate,
> install, manage
> self-signed and/or CA signed digital certs.
>
> This will not just help Manila usecase, but also help GlusterFS provide a
> complete
> solution for digital cert management which will aid the SSL auth support
> feature of GlusterFS
>
> In fact, this can be done in a modular way where in the default implm will
> be that of GlusterD
> cert module, but optionally one can use openstack Barbican service too as a
> cert mgmt service
This one management feature we need add to out list.
>
> 2) In the manila community there was some intense discussion on the
> definition of multi-tenancy
> when applied to storage and network level multi-tenancy was voted as being
> very important in
> Manila cloud usecase. Do we have any thoughts on how GlusterD-2.0 /
> GlusterFS-4.0 can
> look at providing tenant separation at network layer ?
This is a goal for GlusterFS-4.0 and should be discussed along with
that. Our main priority for GlusterD-2.0 is to build a good management
framework first and implement the minimum set of functionality
required to manage a cluster. This will be the base for building the
other features of GlusterFS-4.0, like network multi-tenancy.
GlusterFS-4.0 will have this from the perspetive of providing ability
to serve shares in a private/segmented network. But i think GlusterD
should have the ability to provision/manage the private network/segmentation
and prvoide this network ID ( say ) to GlusterFS as part of volume creation
flow.
Other than that, you also mentioned as part of REST API that
GlusterD should provide ability to query the cluster size, i guess we also
need ability to query the volume size too (currently client needs to mount
, do df -h and get the free/used size, this should be part of REST API) as i
see that it will be helpful in Manila usecase
thanx,
deepak
>
> thanx,
> deepak
>
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
