[Gluster-devel] BitRot design document

[Venky Shankar]

On Sun, Dec 14, 2014 at 12:23 PM, Deepak Shetty <dpkshetty at gmail.com> wrote:
>
>
> On Sat, Dec 13, 2014 at 10:58 PM, Venky Shankar <yknev.shankar at gmail.com>
> wrote:
>>
>> On Sat, Dec 13, 2014 at 4:06 PM, Deepak Shetty <dpkshetty at gmail.com>
>> 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
>