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