lni / dragonboat

A feature complete and high performance multi-group Raft library in Go.
Apache License 2.0
5.06k stars 541 forks source link

Missing GetDiskUsage method #220

Closed jeremyhahn closed 2 years ago

jeremyhahn commented 2 years ago

Dragonboat version

3.3.4

Expected behavior

Code compiles

Actual behavior

github.com/lni/dragonboat/v3/internal/vfs

go/pkg/mod/github.com/lni/dragonboat/v3@v3.3.4/internal/vfs/vfs.go:47:5: cannot use (PebbleFS)(nil) (type PebbleFS) as type "github.com/cockroachdb/pebble/vfs".FS in assignment: *PebbleFS does not implement "github.com/cockroachdb/pebble/vfs".FS (missing GetDiskUsage method)

Steps to reproduce the behavior

Compile using go version go1.17.5 linux/amd64

jeremyhahn commented 2 years ago

I was able to track this down to a newer pebble version in my app's go.mod. My app is also using pebble.

When using go get, it pulls down a newer version - github.com/cockroachdb/pebble v0.0.0-20211222161641-06e42cfa82c0 which produces the GetDiskUsage error above.

When I updated my go.mod to match dragonboats go.mod github.com/cockroachdb/pebble v0.0.0-20210331181633-27fc006b8bfb I was able to get my app to compile.

lni commented 2 years ago

@jeremyhahn thanks for the update.

I had the concern that the exact described problem would eventually happen. On one hand, I'd like to use a well tested version of pebble in dragonboat so that it won't cause surprises, that means a relatively old & stable version of pebble would be picked.

go.mod mechanism doesn't allow two versions of the same module to be used in a project, this means a user selected pebble version will replace dragonboat's pick and potentially cause the above reported issue or users will be forced to use the same relatively old version of pebble in their own components.

sadly I am not aware of any good solution to this issue. Inputs on this will be really appreciated.

jeremyhahn commented 2 years ago

Nothing simple comes to mind, but maybe Dragonboat could take an optional log database in the NodeHostConfig and allow the user to specify their own implementation or use the included pebble log backend by toggling build tags? This would also make it so any backend database could be used, in theory.