RemoteDownload for File.Get()

[ejbrever]

Currently File.Get() supports sending back a byte stream from the device of the file. I would also like to support the device saving the file to another server. This is a common use case that the optical vendors all support today in order to send daily database backups or debug data dumps to a remote server.

I think we could re-use RemoteDownload here: https://github.com/openconfig/gnoi/blob/master/system/system.proto#L280

RemoteDownload could essentially just be another field within GetRequest: https://github.com/openconfig/gnoi/blob/master/file/file.proto#L86

However, we would want to change some of the docstrings of RemoteDownload to specify this use case. I think RemoteDownload should be moved to types.proto as well.

@aashaikh @robshakir Does this sounds reasonable? I can work on a PR if you think it is okay.

[levhuan]

Hello Eric, is this issue being worked on?

I think RemoteDownload should be moved to types.proto to avoid "import cycle" Go build error when we import either gnoi/system or gnoi/file (my environment: Go v1.8.1, grpc v1.9.1, protoc v3.2.0, protobuf v1.0.0, google.golang.org/genproto a8101f21cf983e773d0c1133ebc5424792003214)

@aashaikh @robshakir if no one is working on this, I can work on a PR if needed. Also note, pb.go files in the repo are not in-sync with its proto.

[ejbrever]

HI, I am not currently working on this. If there is a import cycle error, that would be great if you can help fix that! Thanks.

[sabirk05]

Hi, 'RemoteDownload' specifies the path to third location and 'TransferToRemote' pushes file to that RemoteDownload location. Is it have any way to 'Transfer-from-remote'? to pull file for the remote location to the server?

[mukul-11]

Hi, I am facing an issue with using gnmi service and gnmi_file service on the same grpc server. If I register both these services on the grpc server I get an issue due to same named "get" rpc existing in both. Since go does not support function overloading is there a workaround that can support registering these services on same server. A similar conflict is present for the install rpc within OS and CERT services.

[robshakir]

In order to achieve this -- you need to build separate server implementations and then register them on the same listener. For example, in Go, it's roughly this pattern:

type GNOIServer struct {}

func (*GNOIServer) Get(...) (*gnoi.GetResponse, error) { ... }

type GNMIServer struct {}

func (*GNMIServer) Get(...) (*gnmi.GetResponse, error) { ... }

func main() {
        gnoi, gnmi := &GNMIServer{}, &GNOIServer{}
	l, err := net.Listen("tcp", "localhost:0")
	if err != nil {
		t.Fatalf("cannot create listener, got err: %v", err)
	}
	gpb.RegisterGNMIServer(srv, gnmi)
        gnoipb.RegisterGNOIServer(srv, gnoi)
}