Refactor rpc progs

[prashanthpai]

Make Procedure struct available to external package by moving it to sunrpc
package. This is the idiomatic way to let RPC programs to be in their own
independent package while avoiding cyclic imports.

We definitely do not want all sunrpc programs to be put under the
servers/sunrpc directory.

Moves portmap program to it's own package as an example of
package outside of servers/sunrpc

[prashanthpai]

@aravindavk This is what I was mentioning about. The code here doesn't care about where pmap package is located or if it's a glusterd2 plugin or not. If it satisfies the Program interface, it can hook into sunrpc server.

[aravindavk]

cool. In plugins patch, I moved programsList to server/sunrpc/program so that this list can be populated from outside. In this case for pmap changes we need not touch this file.

In pmap package,

import "github.com/gluster/glusterd2/servers/sunrpc/program"

func init(){
    program.AddProgram(NewGfPortmap())
}

program.AddProgram adds to programsList. also expose program.GetProgramList so that you can use it in this file.

In this file import pmap as

_ "github.com/gluster/glusterd2/pmap"

init() func is called when pmap is imported, which adds to programsList

[prashanthpai]

_ "github.com/gluster/glusterd2/pmap"
init() func is called when pmap is imported, which adds to programsList

IMHO this is not a good convention to follow in Go for this purpose. It'll work though. Very often, being explicit is more helpful to new people reading your code.

Here's why I prefer this format:

programsList = []Program{
 		newGfHandshake(),
 		newGfDump(),
		pmap.NewGfPortmap(),}

• If all plugins are imported and added at once place in servers/sunrpc or servers/sunrpc/program package, it's clear to see list of plugins which hook into sunrpc server. I don't have to look at multiple packages. I can also comment out and disable the ones I don't want during my development, all at one place.
• If the plugin resides outside of the repo, those plugins can also be used, simply by importing it them here and explicitly adding the program package
• The constructor (example NewGfPortmap) can be passed arguments (like config or env variable). The plugin won't have to share context/state with glusterd2.
• Every plugin won't have to import github.com/gluster/glusterd2/servers/sunrpc/program.

[aravindavk]

These interfaces(Name, Number, Version, Procedures) are not adding any value, but every sunrpc program has to implement it. All the details already available in the return object of NewGfPortmap. Can sunrpc library modified to use program_object.Name instead of program_object.Name()?

[kshlm]

An interface is just a set of functions, that any type can implement. This is unlike classes in other languages, where the class itself is a type as well as associated functions. So as it is, we cannot directly use the objects returned here.

But looking at the rest of the code, it seems we've been using the same struct everywhere. So we could just define a common struct for a Program and simplify a lot of stuff.

@prashanthpai Can you please do this?

[prashanthpai]

An interface is just a set of functions, that any type can implement. This is unlike classes in other languages, where the class itself is a type as well as associated functions. So as it is, we cannot directly use the objects returned here.

Yep. Go is strongly typed and .Name although is a public field cannot be used across different types.

But looking at the rest of the code, it seems we've been using the same struct everywhere. So we could just define a common struct for a Program and simplify a lot of stuff.

This is still the case for all RPC programs residing in servers/sunrpc. However, programs residing external to this package will have to define their own struct. This is done to avoid having every package which implements RPC programs to import this common struct from servers/sunrpc/program. I could think of only two ways to alleviate this - either have a types package in the root of glusterd2 repo or move it to sunrpc package - both of which didn't feel right. @kshlm Thoughts ?

[kshlm]

As requested in another comment, could you also refactor the rpc Programs themselves to use a common structure.

[kshlm]

Approving the changes and merging. @prashanthpai requested that I do this and he'll send the requested changes in another PR.