nspcc-dev/neofs-node

Refactor node validation in Inner Ring code

Open

#2,578 opened on Sep 14, 2023

View on GitHubContributor guide
 (3 comments) (0 reactions) (0 assignees)Go (49 forks)auto 404
I4S2U4enhancementgood first issueneofs-ir

Repository metrics

Stars
 (36 stars)
PR merge metrics
 (PR metrics pending)

Description

currently Inner Ring verifies and updates descriptors of the storage nodes to be set in the NeoFS network map via https://pkg.go.dev/github.com/nspcc-dev/neofs-node/pkg/innerring/processors/netmap#NodeValidator

it's implemented through several independed packages https://github.com/nspcc-dev/neofs-node/tree/master/pkg/innerring/processors/netmap/nodevalidation

there are two disadvantages in such approach:

  1. since each "small" validator may change descriptor through pointer (e.g. LOCODE one), they must be strictly ordered, so https://pkg.go.dev/github.com/nspcc-dev/neofs-node@v0.38.0/pkg/innerring/processors/netmap/nodevalidation#CompositeValidator becomes unusable. We've already encountered such problem in 4c55307421e75e81a098490eada5dd48e2e20fc2
  2. previous point also happens because different validators work with the same parts. For example, locode, structure and attribute (coming with #2280) work with attributes but stay out of sync, so they must repeat similar checks

i propose to refactor this part of code to make it more simple (e.g. gather in one package) and safe. Power of interfaces will allow us to make it easy to understand and test

Contributor guide

Research direction
Examine the current node validation architecture in the Inner Ring, focusing on the CompositeValidator and individual validators like LOCODE, structure, and attribute. Understand the ordering issue and attribute duplication, then propose a unified package that consolidates validation logic while preserving testability.
Tech stack
go
Domain
backend
Issue type
Refactor
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
Go
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
60