Drop subnets #261
Milestone
Comments
roman-khimov
added a commit
to nspcc-dev/neofs-sdk-go
that referenced
this issue
May 22, 2023
We don't need them and while there are reason to have some remnants in the protocol itself we can remove them from the SDK immediately to not include them into the 1.0.0 release. Refs. nspcc-dev/neofs-api#261.
roman-khimov
added a commit
to nspcc-dev/neofs-sdk-go
that referenced
this issue
May 22, 2023
We don't need them and while there are reason to have some remnants in the protocol itself we can remove them from the SDK immediately to not include them into the 1.0.0 release. Refs. nspcc-dev/neofs-api#261. Signed-off-by: Roman Khimov <[email protected]>
notimetoname
added a commit
to notimetoname/neofs-node
that referenced
this issue
Jun 28, 2023
See nspcc-dev/neofs-api#261. Signed-off-by: Pavel Karpy <[email protected]>
notimetoname
added a commit
to notimetoname/neofs-node
that referenced
this issue
Jun 28, 2023
See nspcc-dev/neofs-api#261. Signed-off-by: Pavel Karpy <[email protected]>
notimetoname
added a commit
to notimetoname/neofs-node
that referenced
this issue
Jun 29, 2023
See nspcc-dev/neofs-api#261. Signed-off-by: Pavel Karpy <[email protected]>
notimetoname
added a commit
to notimetoname/neofs-node
that referenced
this issue
Jun 29, 2023
See nspcc-dev/neofs-api#261. Signed-off-by: Pavel Karpy <[email protected]>
notimetoname
added a commit
to notimetoname/neofs-node
that referenced
this issue
Jun 29, 2023
See nspcc-dev/neofs-api#261. Signed-off-by: Pavel Karpy <[email protected]>
notimetoname
added a commit
to notimetoname/neofs-node
that referenced
this issue
Jun 29, 2023
See nspcc-dev/neofs-api#261. Signed-off-by: Pavel Karpy <[email protected]>
roman-khimov
added a commit
to nspcc-dev/neofs-node
that referenced
this issue
Jun 29, 2023
roman-khimov
added a commit
that referenced
this issue
Dec 16, 2023
Signed-off-by: Roman Khimov <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
They mostly solve the problem of having controlled node groups, but they at the same time exist slightly out of regular placement rules which makes them inconvenient to use while complicating the protocol at the same time. The problem of controlled groups can easily be solved with nspcc-dev/neofs-node#2280 (nspcc-dev/neofs-node#2279 may also be useful in some scenarios), which will fit into the regular placement policy nicely.
This mechanism is not used in the wild, no one really depends on it. We can make our protocol less complex if we're to drop it. The problem mostly is that we've had it in the protocol for a while, so it can't be just removed, it needs to be deprecated, but still kept in many protocol fields to stay compatible (marked as unused/deprecated/always zero/whatever).
The text was updated successfully, but these errors were encountered: