nspcc-dev / nspcc-dev/neofs-node
Container policy violation in dynamic data slicing with TTL=1
Open
Nobody has claimed this yet.
bug
I4
neofs-storage
S3
U3
- Dominant language
- Go
- Stars
- 38
- Forks
- 51
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 38
Description
- user requests slicing data into objects and storing them in the container by attaching session token
- user configures request proxy by TTL field
Expected Behavior
objects are be stored according to container policy (e.g. in 3 replicas) regardless of TTL
Current Behavior
objects are just saved locally
Possible Solution
ignore TTL when slicing is requested
Steps to Reproduce (for bugs)
$ neofs-adm fschain set-config --alphabet-wallets ../devenv/services/ir1/alphabet/ -r http://ir01.neofs.devenv:30333 MaxObjectSize=1000
$ neofs-cli object put -r s01.neofs.devenv:8080 -w ../devenv/wallets/wallet.json --cid GXW6LuwSaeMSHifTY2jpaEcyLg3WPKH7CgjLasKNZ6R3 --file testfile_4k --ttl 1
Context
prepare for #3420
Regression
no
Your Environment
- 832748964dd85ee1f6e7eb2d202380a98508e57b
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start from the neofs-cli object put command and trace how the TTL field affects slicing and container placement, using the reproduction commands and the MaxObjectSize configuration as a starting point. Compare the behavior with the container policy described in the issue and verify that sliced objects are stored according to that policy, including the expected replicas, when TTL is 1.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100