netmap: Introduce Replica method #211
No reviewers
Labels
No labels
P0
P1
P2
P3
good first issue
pool
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
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-sdk-go#211
Loading…
Reference in a new issue
No description provided.
Delete branch "aarifullin/frostfs-sdk-go:fix/ec_total_count"
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?
* Logically, ECShardsCount is mutually exclusive with ReplicaNumberByIndex.* ECShardsCount returns non-zero results if a policy is set byEC
and zero if it is set byREP
. Thus ECShardsCount and ReplicaNumberByIndex can be used to distinguish policies.* Add explanatory comments for the methods.GetCount()
andGetECDataCount
,GetECParityCount
.setIDWithSignature
(we calculate checksum before ID is calculated)2b712ac16f
to38a239fd15
@ -185,1 +185,4 @@
// ECTotalCountByIndex returns the total count of data and parity parts used by EC
// from the i-th replica descriptor. Index MUST be in range [0; NumberOfReplicas()).
func (p PlacementPolicy) ECTotalCountByIndex(i int) uint32 {
The interface for EC is intentionally minimal, we haven't even written in node anything yet, why this PR?
Firstly, I thought we need to distinguish how we set
replicas[i]
- either byREP
or byEC
. Anyway, even the introduced function seems inconvenient, we need to fixReplicaNumberByIndex
then - it should usecountNodes(p.replicas[i])
instread, because it retruns0
for EC policy right nowI have removed this method and fixed
ReplicaNumberByIndex
.Commit message is also fixed. Please, check this out. We need this fix because we need to get
EC
parts total count. But still here is a problem how we can distinguish a replica is set - byREP
or byEC
?Oh, I see what you did.
So it is motivated by internal SDK needs?
Doesn't node selection work right now? Probably missed the test in my initial PR.
Anyway, what about
ECShardsCount (uint32, uint32)
then? It seems if we need total amount from a public method, we also need data and parity?This sounds goods. Anyway, as I said, we need to distinguish the approach and thus
ECShardsCount
seems OK for that38a239fd15
to5007db4579
5007db4579
to56e75743ec
netmap: Introduce ECTotalCountByIndex methodto netmap: Fix ReplicaNumberByIndex method@ -181,3 +181,3 @@
// Zero PlacementPolicy has no replicas.
func (p PlacementPolicy) ReplicaNumberByIndex(i int) uint32 {
return p.replicas[i].GetCount()
return countNodes(p.replicas[i])
Comment needs to be adjusted too.
How do we distinguish between REP and EC policies in existing places?
You suggested the idea I liked -
ECShardsCount (uint32, uint32)
. So,ReplicaNumberByIndex
will be used forREP
polices andECShardsCount
- forEC
56e75743ec
tob42bee3454
@ -2,6 +2,8 @@ module git.frostfs.info/TrueCloudLab/frostfs-sdk-go
go 1.20
replace git.frostfs.info/TrueCloudLab/frostfs-api-go/v2 v2.16.1-0.20240319122301-1772b921826b => git.frostfs.info/aarifullin/frostfs-api-go/v2 v2.15.1-0.20240327095603-491a47e7fe24
This will be fixed as soon as #70 is merged
It is merged.
b42bee3454
to9536991d7d
9536991d7d
tofb4a31d03e
fb4a31d03e
tob59dac7aee
netmap: Fix ReplicaNumberByIndex methodto netmap: Introduce ECShardsCount method@ -182,1 +182,4 @@
//
// If the result is zero, then EC policy might be used - use ECShardsCountByIndex
// to check that.
func (p PlacementPolicy) ReplicaNumberByIndex(i int) uint32 {
I am not wondering:
Consider policer. It could happily remove the replica because
ReplicaNumberByIndex
returns 0. Not saying it will happen, but looks like a probable mistake. In general it seems dangerous for automatic processing. However, returning a non-zero number here is also not perfect.How about returning replica with
Replica(i int) Replica
or may beTypeOf(i int)
and then switch based on type?We can panic if
ReplicaNumberByIndex
is used for EC then.Another option is to add
, bool)
to the return value which signifies success.If policer uses old SDK version, then
ReplicaNumberByIndex
returns 0 for EC anyway.If policer uses new (with EC) SDK version, then policer must know how to deal with EC.
That's the good point. Anyway, we cannot distinguish how
Replica
was set - either byREP
or byEC
because there is no indicating flag. The only way is to use these numbers (approaches suggested by @fyrchik will use counting anyway): ifReplicaNumberByIndex > 0
, thenREP
is used; ifECShardsCount > 0
, thenEC
is used; if they are both zero, then the policer can consider thatReplica
isREP 0
.My point is that it is really easy to forget EC case and it is can be hard to see what was forgotten.
Alright. To avoid the confusion, I've introduced
Replica
method and madeReplicaNumberByIndex
deprecated. So,Replica
allows to checkGetCount()
and if it's> 0
then the policy is set byREP
.EC
is set ifGetECDataCount() + GetECParityCount() > 0
. The SDK's client won't forget this fact since he accessesGetECDataCount(), GetECParityCount()
b59dac7aee
to1c0244baf1
1c0244baf1
toa6dffd2cb9
netmap: Introduce ECShardsCount methodto netmap: Introduce Replica methoda6dffd2cb9
toe1f70fa79d
@ -44,12 +44,12 @@ func (c *Constructor) Split(obj *objectSDK.Object, key *ecdsa.PrivateKey) ([]*ob
}
func setIDWithSignature(obj *objectSDK.Object, key *ecdsa.PrivateKey) error {
objectSDK.CalculateAndSetPayloadChecksum(obj)
Is there some test that fails with the old behaviour? The change seems pretty important, could you write such test?
To check: create parts, then validate header by
CheckHeaderVerificationFields
I added header verification in
TestSplitMaxShardCount
for both cases. Is that okay?It seems it is better to verify it not with separte unit-test for
setIDWithSignature
but when parts are created!@ -184,2 +186,4 @@
}
// Replica returns i-th replica descriptor. Index MUST be in range [0; NumberOfReplicas()).
func (p PlacementPolicy) Replica(i int) *netmap.Replica {
netmap.Replica
- it isapi-go
type. I think it is better to add somesdk
wrapper.Alright. Actually, the same can be said about
object
andcontainer
- they are also confusing names, because we've got the same in api-go :) I renamed the method toReplicaDescriptor
to make entities more distinguishableThe point is that
Object
andContainer
have aliases and are used in node asobjectSDK.Object
dc68f99dad
to0dfd57aa6b
0dfd57aa6b
to34ede4cfaf
34ede4cfaf
to9cf5d4b797
9cf5d4b797
to903e33b311
903e33b311
to0632bfb190
0632bfb190
toec0cb2169f