<html><head></head><body>Does this compare to ViPR? <br><br><div class="gmail_quote">On September 20, 2016 9:52:54 AM PDT, Ric Wheeler <rwheeler@redhat.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 09/20/2016 10:23 AM, Gerard Braad wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Hi Mrugesh,<br /><br /> On Tue, Sep 20, 2016 at 3:10 PM, Mrugesh Karnik <mkarnik@redhat.com> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> I'd like to introduce the Tendrl project. Tendrl aims to build a<br /> management interface for Ceph. We've pushed some documentation to the<br /></blockquote> On Tue, Sep 20, 2016 at 3:15 PM, Mrugesh Karnik <mkarnik@redhat.com> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> I'd like to introduce the Tendrl project. Tendrl aims to build a<br /> management interface for Gluster. We've pushed some documentation to<br /></blockquote> It might help to introduce Tendrl as the "Universal
Storage Manager'"<br /> with a possibility to either manage Ceph and/or Gluster.<br /> I understand you want specific feedback, but a clear definition of the<br /> tool would be helpful.</blockquote><br /><br />(Apologies for reposting my response - gmail injected html into what I thought <br />was a text reply and it bounced from ceph-devel.)<br /><br />Hi Gerard,<br /><br />I see the goal differently.<br /><br />It is better to think of tendryl as one component of a whole management <br />application stack. At the bottom, we will have ceph specific components <br />(ceph-mgr) and gluster specific components (glusterd), as well as other local <br />storage/file system components like libstoragemgt and so on.<br /><br />Tendryl is the next layer up from that, but it itself is meant to be consumed by <br />presentation layers. For a stand alone thing that we hope to use at Red Hat, <br />there will be a universal storage manager stack with everything I mentioned <br />above in it, as
well as the GUI code.<br /><br />Other projects will hopefully find this useful enough and plug some or all of <br />the components into other management stacks.<br /><br /> From my point of view, the job is to try to provide as much as possible <br />re-usable components that will be generically interesting to a wide variety of <br />applications. It is definitely not about trying to make all storage stacks look <br />the same and force artificial new names/concepts/etc on the users. Of course, <br />any one application will tend to have a similar "skin" for UX elements to try <br />and make it consistent for users.<br /><br />If we do it right, people passionate about Ceph but who don't care about Gluster <br />will be able to be avoid getting tied up in something out of their interest. <br />Same going the other way around for Gluster developers who don't care or know <br />about Ceph. Over time, this might extend to other storage types like Samba or <br />NFS Ganesha clusters,
etc.<br /><br />Regards,<br /><br />Ric<br /><br /><br /><br /><br /><hr /><br />Gluster-devel mailing list<br />Gluster-devel@gluster.org<br /><a href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>