Change mode of shard components #1121
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#1121
Loading…
Reference in a new issue
No description provided.
Delete branch "achuprov/frostfs-node:feat/change_mode_shard_components"
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?
Close: #1076
Before:
Read-Only
Read-Write
Degraded-Read-Write
Degraded-Read-Only
After:
Read-Only
Read-Write
Degraded-Read-Write
Degraded-Read-Only
@achuprov why shard mode
Degraded-Read-Only
does matchDEGRADED_READ_ONLY
for writecache? Also whyDegraded-Read-Write
for shard does matchDEGRADED
for writecache?59a2a606e2
tof4b8d4e7e6
f4b8d4e7e6
to9984a67c94
9984a67c94
toe5f7261b38
WIP: feat/change_mode_shard_componentsto feat/change_mode_shard_componentsfeat/change_mode_shard_componentsto Change mode shard componentsChange mode shard componentsto Change mode of shard components@ -18,0 +22,4 @@
|-----------------------|---------------|----------------|-----------------|---------------|-----------------------|-------------|
| `Read-Only` | READ_ONLY | READ_ONLY | READ_ONLY | READ_ONLY | READ_ONLY | READ_ONLY |
| `Read-Write` | READ_WRITE | READ_WRITE | READ_WRITE | READ_WRITE | READ_WRITE | READ_WRITE |
| `Degraded-Read-Write` | CLOSED | READ_WRITE | CLOSED | READ_WRITE | READ_WRITE | READ_WRITE |
Pilorama is also closed in degraded modes.
Fixed
@ -162,3 +162,3 @@
switch s {
case "read-write", "":
m = mode.ReadWrite
m = mode.Mode(mode.ReadWrite)
Looks complex. I think it is better to use consts. Or something like
func ComponentModeFromShardMode()
.Fixed
e5f7261b38
to0cebe75571
@ -117,3 +117,3 @@
require.Equal(t, false, sc.RefillMetabase())
require.Equal(t, mode.ReadOnly, sc.Mode())
require.Equal(t, mode.Mode(mode.ReadOnly), sc.Mode())
FYI: There is also
require.EqualValues
which doesn't require explicit type cast.Don't mind leaving as is.
@ -28,0 +27,4 @@
// DegradedReadOnly is a Mode value for shard that is set automatically
// after a certain number of errors is encountered. It is the same as
// `mode.Degraded` but also is read-only.
DegradedReadOnly = Degraded | ReadOnly
What problem does untyped mode solve?
We have two types:
mode.Mode
andmode.ComponentMode
. The constantsREAD
,READ_WRITE
andCLOSED
should be accessible without type casting.Why don't we introduce a new set of constants?
Fixed
0cebe75571
tobb8329e8d7
bb8329e8d7
tocee5e66bb6
cee5e66bb6
to35df1b665d
35df1b665d
to01c37d8a84
01c37d8a84
toc9cd065b15
@ -123,6 +123,16 @@ func (t *boltForest) Open(_ context.Context, mode mode.Mode) error {
return t.openBolt(mode)
}
func (t *boltForest) getComponentMode(m mode.Mode) mode.ComponentMode {
metabase/mode.go:
writecache/mode.go:
It should all be in one place:
pkg/local_object_storage/shard/mode/mode.go
Moved
Why do we need two different types for shard modes and for component modes? They represent essentially the same concept and just make code harder to read. Can we just add comments to existing
mode.Mode
constants (maybe rename some of them) to specify their usage withShard Components
?Also it would be nice to specify somewhere what those
Shard Components
are.c9cd065b15
tob322c32b98
b322c32b98
to0535ec070f
@ -64,0 +99,4 @@
}
// GetComponentMode maps a ShardMode to a ComponentMode.
func GetComponentMode(m Mode) ComponentMode {
The name is too generic, and the implementation is too narrow:
disabled
case is non-explicit and thus depends on the order ofif
s.0535ec070f
to4cd16e1e8c
@elebedeva You are correct, the concepts are similar. However,
mode.Mode
is responsible for the overall mode of the shard and includes a wider range of modes. Conversely,ComponentsMode
can only be inR
,RW
, orClosed
modes. We could usemode.Mode
for component modes, but this would create additional requirements when usingmode.Mode
, which we would like to avoid.I don't see any changes for
Blobstor.SetMode
in this PR -- it is also a component.My comment for
GetComponentMode
function have appeared because of this.4cd16e1e8c
to6cbcfb764f
6cbcfb764f
toacded3cea9
acded3cea9
to074612f5a0
074612f5a0
to3c95293c8b
3c95293c8b
to0e9226e545
0e9226e545
to3e3b361f0f
@fyrchik Fixed
@ -3,13 +3,15 @@ package common
import (
"context"
"git.frostfs.info/TrueCloudLab/frostfs-node/pkg/local_object_storage/shard/mode"
Please, look at the import groups, we use 2 groups, 1 for stdlib, the second for other.
You might want to adjust the setting of your IDE
3e3b361f0f
to17703f5e16
17703f5e16
toce7500f003