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.
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.
>
> 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.
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 ?
just giving the feature page link can have the reader know the links to all of these other docs ?
There should be one common place from where anyone can navigate to all other related docs
that matter for this feature/functionality
that matter for this feature/functionality
>
> 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
deepak
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
