frostfs-cli: Add EC support to object nodes
#1120
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#1120
Loading…
Reference in a new issue
No description provided.
Delete branch "dstepanov-yadro/frostfs-node:feat/ec_object_nodes"
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?
frostfs-cli object nodes
commandfrostfs-cli object nodes
command doesn't use linking object for complex objects: linking objects store on all container nodes and are not required, so using linking object is uselessfrostfs-cli object nodes
command output to print detailed information about object nodes--json
flag to output result to JSONOutput example:
b3a9364679
to0e81828105
0e81828105
to5742f8e59e
Could you also attach output for EC objects to the description?
Done
So we must use
--explain
for this command to be useful on EC containers?Yes. It is also useful for complex objects and complex EC objects.
I think QA testcases could have some parsers of output, so I decided to print this detailed info only with flag for backward compatibility.
That is ok, because for EC table output is somewhat useless.
I was thinking about some table representation, like this:
or this:
Don't have anything against the current implementation if everyone else is happy, though.
What will it look like for compex EC objects? Complex EC objects consists of parts, but each part is EC has its own chunks.
It could look like this (
part:chunk_index
):Anyway, complex objects are not supported by REP policies too (and your --explain flag handles it well)
I have nothing against leaving only the
explain
part in the output (and drop--explain
flag), if QA does not mind.Why is it
Actual nodes
in the text view andconfirmed_nodes
in JSON view?It also could be nice to have some stable output (like sorting by part index, then by EC index).
Table view is more compact IMO, but this is not a frequently used command, and we can always support more output formats in the future.
a77d6ad69a
toe59cac47cf
Agree, lazy developer detected (it's me). Fixed.
e59cac47cf
tofb44bf51e1
fb44bf51e1
toc5194797ab
c5194797ab
to368218f0cc