TrueCloudLab/frostfs-s3-gw
17
3
Fork 19
Code Issues 28 Pull requests 6 Projects Releases 18 Packages Activity Actions

feature/74-tree_round_robin #77

Merged
realloc merged 1 commit from dkirillov/frostfs-s3-gw:feature/74-tree_round_robin into master 2023-07-26 21:08:00 +00:00
Conversation 1 Commits 1 Files changed 2 +63 -70
dkirillov commented 2023-04-03 14:34:23 +00:00
Member
Copy link

close #74

close #74
dkirillov self-assigned this 2023-04-03 14:34:23 +00:00
dkirillov force-pushed feature/74-tree_round_robin from 244f087002 to 79d33cd741 2023-04-04 06:39:55 +00:00 Compare
dkirillov force-pushed feature/74-tree_round_robin from 79d33cd741 to f0bbd5dcc2 2023-04-04 06:48:09 +00:00 Compare
dkirillov changed title from WIP: feature/74-tree_round_robin to feature/74-tree_round_robin 2023-04-04 06:48:19 +00:00
dkirillov requested review from storage-services-committers 2023-04-04 06:48:28 +00:00
dkirillov requested review from storage-services-developers 2023-04-04 06:48:28 +00:00
alexvanin commented 2023-04-04 06:50:42 +00:00
Owner
Copy link

@a.bogatyrev has some tests for that, so let's invite him to try it.

@a.bogatyrev has some tests for that, so let's invite him to try it.
alexvanin requested review from a.bogatyrev 2023-04-04 06:50:49 +00:00
dkirillov requested review from fyrchik 2023-04-04 06:53:15 +00:00
fyrchik reviewed 2023-04-04 11:23:30 +00:00
api/handler/handlers_test.go Outdated
@ -118,3 +118,3 @@
memCli, err := tree.NewTreeServiceClientMemory()
require.NoError(t, err)
return tree.NewTree(memCli)
return tree.NewTree(memCli, zap.NewExample())
fyrchik commented 2023-04-04 11:23:30 +00:00
Owner
Copy link

Hm, haven't heard about zap.NewExample, how does it differ from zaptest.New(t)

Hm, haven't heard about `zap.NewExample`, how does it differ from `zaptest.New(t)`
dkirillov commented 2023-04-04 12:04:26 +00:00
Author
Member
Copy link

It writes json to stdout without timestamp and calling function. But probably we should use zaptest instead

It writes json to stdout without timestamp and calling function. But probably we should use `zaptest` instead
fyrchik reviewed 2023-04-04 11:24:14 +00:00
docs/configuration.md Outdated
@ -340,0 +340,4 @@
```yaml
tree:
service:
- s01.frostfs.devenv:8080
fyrchik commented 2023-04-04 11:24:14 +00:00
Owner
Copy link

On a side-note, why do we have a separate section for the tree service?

On a side-note, why do we have a separate section for the tree service?
alexvanin commented 2023-04-04 11:33:50 +00:00
Owner
Copy link

Back in the days tree service was served on a separate port from FrostFS API.

Back in the days tree service was served on a separate port from FrostFS API.
fyrchik commented 2023-04-05 05:03:05 +00:00
Owner
Copy link

Maybe now is the time to move? We already have a list for "normal" endpoints.

Maybe now is the time to move? We already have a list for "normal" endpoints.
alexvanin commented 2023-04-05 06:26:29 +00:00
Owner
Copy link

We plan to use "normal" endpoints after integrating tree service with the SDK Pool component (#45). For now consider this as a effortless kludge which will be removed anyway.

We plan to use "normal" endpoints after integrating tree service with the SDK Pool component (#45). For now consider this as a effortless kludge which will be removed anyway.
fyrchik reviewed 2023-04-04 11:29:18 +00:00
internal/frostfs/services/tree_client_grpc.go Outdated
@ -284,0 +367,4 @@
return
}
func (c *ServiceClientGRPC) requestWithRetry(fn func(treeClient) error) (err error) {
fyrchik commented 2023-04-04 11:29:18 +00:00
Owner
Copy link

Not that it matters, but how about something like this:

func (c *ServiceClientGRPC) requestWithRetry[Req any, Resp any](req *Req, fn func(treeClient, req *Req) (*Resp, error)) (*Resp, error) {
	for _, client := range c.clients {
		res, err := fn(client, req)
		if !shouldTryAgain(err) {
			return res, err
		}
		c.log.Debug("tree request failed", zap.String("address", client.address), zap.Error(err))
	}

	return nil, errors.New("some error")
}

Can avoid per-method wrappers with this.

Not that it matters, but how about something like this: ``` func (c *ServiceClientGRPC) requestWithRetry[Req any, Resp any](req *Req, fn func(treeClient, req *Req) (*Resp, error)) (*Resp, error) { for _, client := range c.clients { res, err := fn(client, req) if !shouldTryAgain(err) { return res, err } c.log.Debug("tree request failed", zap.String("address", client.address), zap.Error(err)) } return nil, errors.New("some error") } ``` Can avoid per-method wrappers with this.
👍 1
dkirillov force-pushed feature/74-tree_round_robin from f0bbd5dcc2 to 276427d70e 2023-04-04 13:11:55 +00:00 Compare
ironbee reviewed 2023-04-04 13:40:47 +00:00
internal/frostfs/services/tree_client_grpc.go Outdated
@ -284,0 +330,4 @@
type grpcFunc[Req any, Resp any] func(context.Context, Req, ...grpc.CallOption) (Resp, error)
func requestWithRetry[Req any, Resp any](ctx context.Context, req Req, c *ServiceClientGRPC, fn func(client treeClient) grpcFunc[Req, Resp]) (res Resp, err error) {
for _, client := range c.clients {
ironbee commented 2023-04-04 13:40:47 +00:00
Contributor
Copy link

Current implementation uses any available client in the c.clients that comes up first thus we use the clients in the beginning more often that the ones in the end of it. Also, we iterate through some part of the list on each request going through requestWithRetry. I don't insist but may be we should change this?

All implementations of round-robin approaches that I know suppose a cycling system: we go through a set of resources and distribute them one by one from start of a "list" to the end, and then we start over again. This way we achieve somewhat equal utilisation and don't have to look through a "list" of resources every time we need one.

Example of a round-robin approach: https://en.wikipedia.org/wiki/Round-robin_scheduling

Current implementation uses any available client in the `c.clients` that comes up first thus we use the clients in the beginning more often that the ones in the end of it. Also, we iterate through some part of the list on each request going through `requestWithRetry`. I don't insist but may be we should change this? All implementations of round-robin approaches that I know suppose a cycling system: we go through a set of resources and distribute them one by one from start of a "list" to the end, and then we start over again. This way we achieve somewhat equal utilisation and don't have to look through a "list" of resources every time we need one. Example of a round-robin approach: https://en.wikipedia.org/wiki/Round-robin_scheduling
dkirillov commented 2023-04-04 14:10:28 +00:00
Author
Member
Copy link

Good point. I'll change behavior to start iterate client at the index where we stop previously.

As I understand we cannot drop iterating clients at all because we want to retry failed request

/cc @alexvanin @a.bogatyrev

Good point. I'll change behavior to start iterate client at the index where we stop previously. As I understand we cannot drop iterating clients at all because we want to retry failed request /cc @alexvanin @a.bogatyrev
ironbee approved these changes 2023-04-04 16:29:23 +00:00
dkirillov force-pushed feature/74-tree_round_robin from 2d9605dc91 to aca55c6d2f 2023-04-05 06:09:03 +00:00 Compare
dkirillov force-pushed feature/74-tree_round_robin from 9702998350 to c4dfd06377 2023-04-11 12:40:02 +00:00 Compare
dkirillov force-pushed feature/74-tree_round_robin from c4dfd06377 to ac177dab2e 2023-04-17 06:50:58 +00:00 Compare
dkirillov requested review from ironbee 2023-04-17 06:53:39 +00:00
ironbee approved these changes 2023-04-18 09:38:25 +00:00
dkirillov added 1 commit 2023-04-19 12:30:46 +00:00 
Signed-off-by: Artem Tataurov <a.tataurov@yadro.com>
dkirillov force-pushed feature/74-tree_round_robin from 35b7c3abc2 to d682487c9c 2023-04-19 14:48:33 +00:00 Compare
dkirillov force-pushed feature/74-tree_round_robin from d682487c9c to ce11fd3757 2023-04-21 09:02:24 +00:00 Compare
dkirillov force-pushed feature/74-tree_round_robin from ce11fd3757 to 69d8779daf 2023-04-26 13:40:11 +00:00 Compare
a.bogatyrev approved these changes 2023-04-26 13:42:11 +00:00
dkirillov requested review from storage-services-developers 2023-04-26 13:42:32 +00:00
ironbee approved these changes 2023-04-26 13:47:28 +00:00
pogpp approved these changes 2023-04-27 07:30:32 +00:00
realloc merged commit 69d8779daf into master 2023-04-27 07:33:57 +00:00
realloc deleted branch feature/74-tree_round_robin 2023-04-27 07:33:58 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
fyrchik
a.bogatyrev
ironbee
pogpp
TrueCloudLab/storage-services-committers
Labels
Clear labels   
P0

Highest

  
P1

High

  
P2

Medium

  
P3

Low

  
good first issue

Good for newcomers

  
Infrastructure

Infrastructure, Automation, CI/CD or DevOps related stuff

  
blocked

The issue or PR is blocked by something

  
bug

Something is not working

  
config

Configuration format update or breaking change

  
discussion

Talking about something in order to reach a decision or to exchange ideas

  
documentation

Documentation related

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
go

Language features adoption

  
help wanted

Extra attention is needed

  
internal

   
invalid

Something is wrong

  
kludge

This is a kludge and we know it

  
observability

Related to metrics, tracing and logs

  
perfomance

Perfomance related

  
question

More information is needed

  
refactoring

Refactoring

  
wontfix

This won't be fixed

No labels
P0
P1
P2
P3
good first issue
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
dkirillov
6 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-s3-gw#77
No description provided.
Delete branch "dkirillov/frostfs-s3-gw:feature/74-tree_round_robin"

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?