WIP: [#131] add netmap-aware dialer #196
No reviewers
Labels
No labels
P0
P1
P2
P3
good first issue
pool
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-sdk-go#196
Loading…
Reference in a new issue
No description provided.
Delete branch "olefirenque/frostfs-sdk-go:173-add_netmap_aware_dialer"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Refers to #173
@ -6,2 +6,4 @@
"crypto/tls"
"errors"
"fmt"
netmap "git.frostfs.info/TrueCloudLab/frostfs-api-go/v2/netmap/grpc"
stdlib imports should form a separate group, could you move
netmap
below?stdlib imports should form a separate group, could you move
netmap
below?Also, we have netmap in the SDK (this repo), can we use it instead of the api package?
Yes, I used the grpc domain by mistake.
Fixed.
@ -113,0 +119,4 @@
return err
}
isEqualSlices := func(a, b []byte) bool {
Use
bytes.Equal
?@ -113,0 +135,4 @@
nodes := c.prm.NetMap.GetNodes()
for _, node := range nodes {
if isEqualSlices([]byte(u.Host), node.PublicKey) {
return c.Dial(ctx, PrmDial{Endpoint: node.Addresses[0]})
This is where we can implement any logic we need. I suggest moving this
dial
in a separate function, we might want:ExternalAddresses
attributeIt would be easier to do this in a separate function, in this one we have a simple
dial
.Should each option be explicitly defined by client user?
We can discuss. IMO this could be governed with a single parameter, with some reasonable default.
2b9eaeb2a6
to7b03c3a6a1
Since
rpc.Balance
is a static function inClient.Dial(...)
call, it is hard to reach high coverage of Dial/NetMapDial methods. Would it be suitable to extract rpc call to grpc client for inverting the dependency?Also I'm concerned about backward compatibility in case of modification prmDial structure (some of field were extracted in the embedding in the last commit). Maybe it would be convenient to have constructors for such types?
Pull request closed