[#270] Add IR epoch tick control call #282
No reviewers
Labels
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
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#282
Loading…
Reference in a new issue
No description provided.
Delete branch "ale64bit/frostfs-node:feature/270-cmd-control-ir"
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?
Signed-off-by: Alejandro Lopez a.lopez@yadro.com
@ -0,0 +12,4 @@
var tickEpochCmd = &cobra.Command{
Use: "tick-epoch",
Short: "Forces a new epoch",
Long: "Forces a new epoch. Note that it is not guaranteed to succeed, although it will with high probability.",
:)
Can we add the probability value? (It is a joke)
Well :) it's not a constant value anyway. But >95%, so likely enough.
This command sends a notary request, so it always succeeds.
Can we mention this and that the command must be executed on other IR nodes?
done
Why don't use frostfs-adm force new epoch command?
There's more info about it in the original issue, including this very same question: https://github.com/nspcc-dev/neofs-node/issues/1866#issuecomment-1273774642.
@ -16,7 +16,7 @@ func (np *Processor) HandleNewEpochTick(ev event.Event) {
// send an event to the worker pool
err := np.pool.Submit(func() { np.processNewEpochTick() })
Unrelated to the commit
done
@ -907,0 +908,4 @@
// probability of all nodes producing the same transaction, since it depends
// on this value.
if controlTx {
const minInc = 100
Using
MaxValidUntilBlockIncrement
here will achieve the same with higher probability.done
@ -106,1 +111,4 @@
// SetControlTX sets whether a control transaction will be used.
func (i *InvokePrmOptional) SetControlTX(b bool) {
i.controlTX = b
What about using
calculateVUB
as a parameter instead of less descriptivecontrolTX
?discussed offline. Renamed to
roundBlockHeight
and added additional comment.@ -16,3 +16,2 @@
type healthCheckResponseWrapper struct {
m *HealthCheckResponse
type responseWrapper[M grpc.Message] struct {
Unrelated to the commit
It's used by
sendUnary
.@ -35,0 +38,4 @@
//
// If request is not signed with a key from white list, permission error returns.
func (s *Server) TickEpoch(_ context.Context, req *control.TickEpochRequest) (*control.TickEpochResponse, error) {
// verify request
We have this such comments in code, but IMO they are not needed, especially when the function is called
isValidRequest
done
0d978bb21d
to0ba646aedc
@fyrchik, dont we want to search for already prepared TX in mempool (or how it is named for notary service) via some
neo-go
RPC (does it exists?)? it would sound more naturally to me: only the first Alphabet node inits notary request while the others just look for it and add their signatures, and not try to predict how the common for all nodes TX should look (via rounding and so on)Mempool is a hash-map, how do you want to search it?
In future we could listen for a notary event and remember some txs in the control service, "approving" them with a separate command.
@ -9,3 +9,3 @@
// NewEpoch updates FrostFS epoch number through
// Netmap contract call.
func (c *Client) NewEpoch(epoch uint64) error {
// If `force` is true, this call is normally initiated by a control
Why is it called
force
then?what should it be called?
@ -290,3 +290,3 @@
}
nonce, vub, err := c.CalculateNonceAndVUB(prm.hash)
nonce, vub, err := c.CalculateNonceAndVUB(prm.hash, false)
What about a separate function? Like
CalculateNonceAndVUBControl
?It serves 1 use-case only and it is not immediately obvious what is the meaning of
false
/true
when reading code.done
0ba646aedc
toaf7e288e4a