Remove subnet support #21

New issue

Closed

opened 2023-04-13 09:25:39 +00:00 by alexvanin · 0 comments

alexvanin commented

2023-04-13 09:25:39 +00:00

Owner

Subnetwork is a set of storage nodes and containers with specific attribute. Subnetworks were introduced to split homogeneous network into parts. This allows to:

control what exact nodes are the part of the subnetwork and store data in the FrostFS but only in controlled nodes,
tweak some incentive models here, e.g. store data in the subnetwork containers for free.

(1) is important, because network map allows any node to come in and use almost any attribute. If user wants to share storage infrastructure and store data on it, one can define some attribute for storage nodes and use it in placement policy. However inner ring will allow any other node with the same attribute become a part of such placement policy. With subnetworks user may manually approve nodes based on node public keys.

This mechanism was not adopted in the public network, because network were relatively small and no third-parties adopt this workflow to share storage infrastructure.

As for private installation, they all need homogeneous storage by definition.

Describe the solution you'd like

Remove subnet definitions of the subnetworks, including attribute description for container and node info,
Remove subnet checks in inner ring,
Remove subnet support in frostfs-cli

Additional context

Follow ups:

api-go issues #to-be-done
sdk issue #to-be-done
node issue #to-be-done

This is an issue from the series of incompatible protocol changes. The purpose of these changes is to rework some FrostFS protocol mechanisms which were non-demanding for the users in private and public networks or they provide unnecessary complexity in the protocol and its implementation. ## Is your feature request related to a problem? Please describe. Subnetwork is a set of storage nodes and containers with specific attribute. Subnetworks were introduced to split homogeneous network into parts. This allows to: 1) control what exact nodes are the part of the subnetwork and store data in the FrostFS but only in controlled nodes, 2) tweak some incentive models here, e.g. store data in the subnetwork containers for free. (1) is important, because network map allows any node to come in and use almost any attribute. If user wants to share storage infrastructure and store data on it, one can define some attribute for storage nodes and use it in placement policy. However inner ring will allow any other node with the same attribute become a part of such placement policy. With subnetworks user may manually approve nodes based on node public keys. This mechanism was not adopted in the public network, because network were relatively small and no third-parties adopt this workflow to share storage infrastructure. As for private installation, they all need homogeneous storage by definition. ## Describe the solution you'd like - Remove subnet definitions of the subnetworks, including attribute description for container and node info, - Remove subnet checks in inner ring, - Remove subnet support in frostfs-cli ## Additional context Follow ups: - api-go issues #to-be-done - sdk issue #to-be-done - node issue #to-be-done