On Sun, Dec 14, 2014 at 12:23 PM, Deepak Shetty <dpkshetty@xxxxxxxxx> wrote: > > > On Sat, Dec 13, 2014 at 10:58 PM, Venky Shankar <yknev.shankar@xxxxxxxxx> > wrote: >> >> On Sat, Dec 13, 2014 at 4:06 PM, Deepak Shetty <dpkshetty@xxxxxxxxx> >> wrote: >> > It would be good to add few usecases to the document for completeness. I >> > would say add usecases first, then the design should follow so that its >> > a >> > good logical flow for the reader. >> > >> > Few that i can think of: >> > >> > 1) Archival/Compliance usecase >> >> That's the major use case. But it does has a wide variety of use cases. > > > It would be good to document those.. atleast 2-3 lines for each usecase. > These would eventually help consumers figure where all BitRot can fit and > thus can > showcase the potential consumers for this feature/functionality. Feature > page could > be a good place to add usecases. I (for my openstack requirements) had added > Usecase as a new section in feature page, you might want to do the same. I linked this mail thread in the feature page. I'll add a use case section too. Thanks for the valuable comments. > > >> >> >> > >> > 2) Openstack cinder usecase - GlusterFS can act as a backup target for >> > Cinder where we can have the bitrot functionality enabled, can help act >> > as a >> > differentiator and attraction for using glusterfs as a backup target >> > >> > 3) Gluster health usecase - BitRot can potentially act as *one* of the >> > indicators for the health of gluster volume, which can pave way for >> > 'gluster >> > health status' kind of a new command. See "BitRot Notes" thread for more >> > info on gluster health cmd i proposed >> >> Good that you've mentioned it here. I'll put this up in the bitrot feature >> page. >> >> > >> > ----------------- >> > >> > It would also be good to add high level steps a storage admin has to >> > take to enable BitRot, what he/she should do when an error gets reported >> > by >> > BitRot, how to check for errors etc. Visualising this would help the >> > interface/CLI effort and also gives a better picture for mgmt applns >> > (eg: >> > openstack) on what it needs to do (since it would try to >> > automate/orchestrate what otherwise admin would have done) >> >> Agreed. The interface specification doc was also written at about the >> same time as the design and can be accessed here: http://goo.gl/2o12Fn >> >> Credit goes to Rachana for preparing this doc. > > > @racpatel - nice work. > I added few comments/suggestions to your CLI doc.. pls have a look. Yes, let's discuss comments specific to the doc there. > > Also looks like there are numerous docs for someone to refer to.... > * feature page > * CLI doc > * design doc > * silent-corruption.doc - which was referred to in this thread > > Is there a way all of these can be referenced from the feature page so that > just giving the feature page link can have the reader know the links to all > of these other docs ? I've added a section for "design and cli specification" which links the two documents mentioned in this thread. > > There should be one common place from where anyone can navigate to all other > related docs > that matter for this feature/functionality Absolutely, the starting point _is the_ feature page. > >> >> >> > >> > Also, could you provide some high level view of how the CLIs for BitRot >> > would look like ? That would help me map to the cinder usecase ( see (2) >> > above ) >> >> As above. The interface is not set in stone, it's just a start. Let us >> know your views. > > > I just added few suggestions, pls have a look > > thanx,. > deepak > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
