node, ir, morph: Add new config option upgrade_mode
#1072
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
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#1072
Loading…
Reference in a new issue
No description provided.
Delete branch "acid-ant/frostfs-node:bugfix/upgrade-flag"
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?
Set scope
None
for notary cosigners when node in upgrade mode.Signed-off-by: Anton Nikiforov an.nikiforov@yadro.com
node, ir, morph: Add new config optionto WIP: node, ir, morph: Add new config optionupgrade_mode
upgrade_mode
cd9fa1751a
to0d798fb33e
0d798fb33e
to6543b68144
WIP: node, ir, morph: Add new config optionto node, ir, morph: Add new config optionupgrade_mode
upgrade_mode
@ -111,1 +107,4 @@
}
// is node in the upgrade mode
isUpgrade *bool
Maybe there is no data race (hard do check, honestly), but what prevents us from using atomic right away?
Thought that here it is redundant, but I don't mind using it.
@ -41,6 +41,7 @@ governance:
node:
persistent_state:
path: .frostfs-ir-state # Path to application state file
upgrade_mode: false # Indicates that node is in upgrade mode
More like
compatibility_mode
(upgrade
is a verb and suggests we upgrade something in node)And can we make it have
kludge_
prefix?Renamed to
node.kludge_compatibility_mode
.@ -47,2 +47,3 @@
"ca": "/ca/path"
}
},
"upgrade_mode": false
Do we need this in node?
Do we need this in node?
Removed this option from description. If you are asking about do we need to run
node
in compatibility mode too - I thought yes.6543b68144
to32aef896e9
32aef896e9
toebb3ba5204
Revert changes related to refactoring of
applicationConfiguration.readConfig()
.@ -569,0 +570,4 @@
// We must be able to call NNS contract indirectly from the Container contract.
// Thus, CalledByEntry is not sufficient.
// In future we may restrict this to all the usecases we have.
scopes := transaction.Global
I would argue that we do not need this in master, this is useful for 0.37 -- 0.38 upgrade, would be useless for 0.38--0.39
Absolutely agree. Removed this commit at all.
26d50f31c4
toffb1a6f81a