Hi All, This mail is an invite to all feature users/owners for your participation for coming up with the REST API for feature specific command semantics. GlusterD 2.0 will work as a REST server and with that all commands need to have REST end points. The goal here is to support the existing semantics as well as introduce new ones if required. We would like to hear from you about what changes does every feature want to see in them in terms of usage and simplicity and this is why an early involvement will be very crucial and handy. You could refer to the documentation [1] on how to define the REST end points for a command. This can be used as a guide to porting feature specific commands into the new GlusterD 2.0 codebase. Along with this, we also need to work on a model where every features can work as a pluggable module to GlusterD. The whole idea behind this approach is to make GlusterD code as light as possible and independent of other features. Off late with a non pluggable module which we have for current GlusterD, maintainability becomes a huge issue as every new features/CRs touches GlusterD code. During our design discussion last week we had an extensive discussion on this and you could find the recording of the session [2]. I am also attaching the slide deck which we referred for GlusterD 2.0 discussion for your reference. And I believe we need a distributed effort from all of the feature owners to get them integrated in GlusterD 2.0 GlusterD 2.0 ongoing development is now been hosted in gluster github and can be found at [3] We look forward for your active contribution to this project. [1] https://github.com/gluster/glusterd2/blob/master/commands/doc.go [2] https://www.youtube.com/watch?v=iBFfHv4bne8 [3] https://github.com/gluster/glusterd2 Thanks, GlusterD team
Attachment:
GlusterD2.0-1.odp
Description: application/vnd.oasis.opendocument.presentation
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
