TrueCloudLab/frostfs-node
21
1
Fork 27
Code Issues 108 Pull requests 3 Projects Releases 2 Activity Actions

[#963] node: Go on initialization even deposit notary is hung #1014

Merged
fyrchik merged 1 commit from aarifullin/frostfs-node:fix/963-control_svc_iface_down into master 2024-03-12 10:18:18 +00:00
Conversation 10 Commits 1 Files changed 4 +24 -2
aarifullin commented 2024-02-29 15:33:52 +00:00
Member
Copy link
  • Make makeAndWaitNotaryDeposit run asynchronously as worker during application boot-up.

It may happen that boot-up waits for the execution of a notary deposit transaction and waiting loop may hang for an indefinite time. In this case, we need to let frostfs-node go on initialization, although its functionality will be available partially - the initial motivation was successfuly initialize control service to make control API available no matter which morph problems occur

Close #963

* Make makeAndWaitNotaryDeposit run asynchronously as worker during application boot-up. It may happen that boot-up waits for the execution of a notary deposit transaction and waiting loop may hang for an indefinite time. In this case, we need to let frostfs-node go on initialization, although its functionality will be available partially - the initial motivation was successfuly initialize control service to make control API available no matter which morph problems occur Close #963
aarifullin requested review from storage-core-committers 2024-02-29 15:34:04 +00:00
aarifullin requested review from storage-core-developers 2024-02-29 15:34:11 +00:00
aarifullin added the
frostfs-node
 label 2024-02-29 15:34:21 +00:00
aarifullin force-pushed fix/963-control_svc_iface_down from 5d95e29bce to aa8cf973e3 2024-02-29 15:52:55 +00:00 Compare
fyrchik commented 2024-02-29 19:01:09 +00:00
Owner
Copy link

Hm, so now some tests may be tricked by the healthcheck: it will show ready when in reality nothing could be done with the node (even Object.GET requires getting container from the blockchain).
We need to see how the integration tests will react, have you tried running them locally?

Hm, so now some tests may be tricked by the healthcheck: it will show ready when in reality nothing could be done with the node (even Object.GET requires getting container from the blockchain). We need to see how the integration tests will react, have you tried running them locally?
fyrchik commented 2024-03-01 07:16:35 +00:00
Owner
Copy link

Also, do we have Warn logs if deposit is not handled?

Also, do we have Warn logs if deposit is not handled?
aarifullin commented 2024-03-01 07:45:32 +00:00
Author
Member
Copy link

have you tried running them locally?

No, I didn't. But I will try - it is definitely inappropriate to run them against dev-env

> have you tried running them locally? No, I didn't. But I will try - it is definitely inappropriate to run them against dev-env
aarifullin commented 2024-03-01 07:51:55 +00:00
Author
Member
Copy link

Also, do we have Warn logs if deposit is not handled?

So, in the case of error, makeAndWaitNotaryDeposit forcefully finishes the application fatalOnError, fatalOnError

It means, that if wait-loop finally is broken due to error, the partially-functioning application fatally exits.

> Also, do we have Warn logs if deposit is not handled? - [waitNotaryDeposit](https://git.frostfs.info/TrueCloudLab/frostfs-node/src/branch/master/cmd/frostfs-node/morph.go#L159-L183) returns error - [makeNotaryDeposit](https://git.frostfs.info/TrueCloudLab/frostfs-node/src/branch/master/cmd/frostfs-node/morph.go#L151) returns error So, in the case of error, `makeAndWaitNotaryDeposit` forcefully finishes the application [fatalOnError](https://git.frostfs.info/TrueCloudLab/frostfs-node/src/branch/master/cmd/frostfs-node/morph.go#L120), [fatalOnError](https://git.frostfs.info/TrueCloudLab/frostfs-node/src/branch/master/cmd/frostfs-node/morph.go#L131) It means, that if wait-loop finally is broken due to error, the partially-functioning application fatally exits.
fyrchik commented 2024-03-01 08:06:16 +00:00
Owner
Copy link

It would be nice to have Warn logs while polling for result, because the node is not fully functional during this.

It would be nice to have Warn logs while polling for result, because the node is not fully functional during this.
aarifullin commented 2024-03-01 08:09:11 +00:00
Author
Member
Copy link

It would be nice to have Warn logs while polling for result, because the node is not fully functional during this.

Alright 👍

> It would be nice to have Warn logs while polling for result, because the node is not fully functional during this. Alright 👍
fyrchik commented 2024-03-05 07:44:52 +00:00
Owner
Copy link

Can we also ensure that we have STARTING in the healthcheck if any of this is false:

  1. Node has finished initialization.
  2. Background notary waiter has exited.
Can we also ensure that we have `STARTING` in the healthcheck if any of this is false: 1. Node has finished initialization. 2. Background notary waiter has exited.
aarifullin force-pushed fix/963-control_svc_iface_down from aa8cf973e3 to 5c16240335 2024-03-07 09:12:10 +00:00 Compare
aarifullin commented 2024-03-07 09:16:21 +00:00
Author
Member
Copy link

Can we also ensure that we have STARTING in the healthcheck if any of this is false:

  1. Node has finished initialization.
  2. Background notary waiter has exited.

I suppose this proposal works only for the second case.
The other workers like

c.workers = append(c.workers, newWorkerFromFunc(func(ctx context.Context) {
		c.treeService.Start(ctx)
	}))

do not "freeze" initialization of some components - so, they do not need to inidicate they are ready.
I have introduced switching healthcheck status after notary deposit job is done. But I have to check it with failover tests and I'll tell if they are not broken

UPD: ran failovers, the result looks fine

> Can we also ensure that we have `STARTING` in the healthcheck if any of this is false: > 1. Node has finished initialization. > 2. Background notary waiter has exited. I suppose this proposal works only for the second case. The other workers like ```go c.workers = append(c.workers, newWorkerFromFunc(func(ctx context.Context) { c.treeService.Start(ctx) })) ``` do not "freeze" initialization of some components - so, they do not need to inidicate they are ready. I have introduced switching healthcheck status after `notary deposit` job is done. But I have to check it with failover tests and I'll tell if they are not broken UPD: ran failovers, the result looks fine
aarifullin force-pushed fix/963-control_svc_iface_down from 5c16240335 to 78dd55088b 2024-03-07 09:22:55 +00:00 Compare
fyrchik approved these changes 2024-03-07 11:34:05 +00:00
fyrchik approved these changes 2024-03-07 11:36:26 +00:00
fyrchik left a comment
Owner
Copy link

What about logs in waitNotaryDeposit?
We can log success with INFO and subsequent attempts in loops with DEBUG

What about logs in `waitNotaryDeposit`? We can log success with INFO and subsequent attempts in loops with DEBUG
aarifullin force-pushed fix/963-control_svc_iface_down from 78dd55088b to 74328ff8ee 2024-03-11 11:48:06 +00:00 Compare
aarifullin commented 2024-03-11 11:48:28 +00:00
Author
Member
Copy link

What about logs in waitNotaryDeposit?
We can log success with INFO and subsequent attempts in loops with DEBUG

Alright. I have added helpful debug and info logs

> What about logs in `waitNotaryDeposit`? > We can log success with INFO and subsequent attempts in loops with DEBUG Alright. I have added helpful debug and info logs
acid-ant approved these changes 2024-03-11 13:25:07 +00:00
fyrchik reviewed 2024-03-11 18:37:38 +00:00
internal/logs/logs.go Outdated
@ -159,2 +159,4 @@
ClientNotaryRequestWithPreparedMainTXInvoked = "notary request with prepared main TX invoked"
ClientNotaryRequestInvoked = "notary request invoked"
ClientNotaryDepositTransactionWasSuccessfullyPersisted = "notary deposit transaction was successfully persisted"
ClientAttemptToWaitForNotaryDepositTransactionGetsPersisted = "attempt to wait for notary deposit transaction gets persisted"
fyrchik commented 2024-03-11 18:37:38 +00:00
Owner
Copy link

It is either for notary deposit transaction to get persisted or until notary deposit transaction is persisted

It is either `for notary deposit transaction to get persisted` or `until notary deposit transaction is persisted`
aarifullin commented 2024-03-11 20:59:59 +00:00
Author
Member
Copy link

Fixed: I preferred the first one

Fixed: I preferred the first one
fyrchik approved these changes 2024-03-11 18:37:48 +00:00
aarifullin force-pushed fix/963-control_svc_iface_down from 74328ff8ee to c86e6582fe 2024-03-11 20:59:34 +00:00 Compare
aarifullin requested review from acid-ant 2024-03-11 21:00:28 +00:00
aarifullin requested review from fyrchik 2024-03-11 21:00:29 +00:00
acid-ant reviewed 2024-03-12 05:59:42 +00:00
cmd/frostfs-node/morph.go Outdated
@ -158,6 +158,7 @@ var (
func waitNotaryDeposit(ctx context.Context, c *cfg, tx util.Uint256) error {
for i := 0; i < notaryDepositRetriesAmount; i++ {
c.log.Debug(logs.ClientAttemptToWaitForNotaryDepositTransactionGetsPersisted)
acid-ant commented 2024-03-12 05:59:42 +00:00
Member
Copy link

ClientAttemptToWaitForNotaryDepositTransactionGetsPersisted -> ClientAttemptToWaitForNotaryDepositTransactionToGetPersisted

ClientAttemptToWaitForNotaryDepositTransactionGetsPersisted -> ClientAttemptToWaitForNotaryDepositTransactionToGetPersisted
fyrchik commented 2024-03-12 07:13:33 +00:00
Owner
Copy link

cmd/frostfs-node/morph.go:161:20: undefined: logs.ClientAttemptToWaitForNotaryDepositTransactionGetsPersisted

`cmd/frostfs-node/morph.go:161:20: undefined: logs.ClientAttemptToWaitForNotaryDepositTransactionGetsPersisted`
aarifullin force-pushed fix/963-control_svc_iface_down from c86e6582fe to 921a43fc10 2024-03-12 07:16:14 +00:00 Compare
acid-ant approved these changes 2024-03-12 07:18:03 +00:00
fyrchik approved these changes 2024-03-12 10:17:42 +00:00
fyrchik merged commit b4cb54e7ed into master 2024-03-12 10:18:18 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
acid-ant
fyrchik
TrueCloudLab/storage-core-developers
Labels
Clear labels   
P0

Highest

  
P1

High

  
P2

Medium

  
P3

Low

  
badger

Badger DB related issues

  
frostfs-adm

   
frostfs-cli

   
frostfs-ir

   
frostfs-lens

   
frostfs-node

   
good first issue

Good for newcomers

  
triage
  
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
badger
frostfs-adm
frostfs-cli
frostfs-ir
frostfs-lens
frostfs-node
good first issue
triage
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
3 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-node#1014
No description provided.
Delete branch "aarifullin/frostfs-node:fix/963-control_svc_iface_down"

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?