-
Notifications
You must be signed in to change notification settings - Fork 50
cli: unify usage of expired-at flag instead of lifetime flag #2521
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2521 +/- ##
=======================================
Coverage 29.68% 29.69%
=======================================
Files 404 404
Lines 30711 30711
=======================================
+ Hits 9117 9119 +2
+ Misses 20825 20823 -2
Partials 769 769 see 1 file with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
ef0ba01 to
0966733
Compare
carpawell
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cthulhu-rider, @roman-khimov, have we decied to deprecate lifetime? I find it usefull if you do not want to look for the current epoch number. I can imagine the future where every cmd has both expire-at and lifetime (or a better naming option).
|
We can disduss it. IMO, both may be helpfull but for every command then cause that is what meant by "unify". Let's wait for other's' opinions. |
|
from my pov as user, i don't find it convenient to work with an absolute epoch value for example, current epoch is if we imagine user or script that requests absolute value may be useful when user wanna specify "infinite" value (extremely big or even max). We can also cover this with lifetime value saves user from past epoch setting, while absolute value allows to test fault conditions (e.g. in neofs-testcases) lifetime won't work if command doesn't accept NeoFS network endpoint in total, i'd support both flags in all commands and make them mutual exclusive: if both set, command fails (i don't like priorities, pls set one or nothing) |
I don't think so, you may want to add things over time that should expire all at once. Suppose you have some process running for a day producing content to be stored in NeoFS, but that should be deleted eventually. It'd be a bit inconvenient to have it expire piece by piece in different epochs.
But I absolutely agree with that, it's not hard to have both. |
yeah, good example for absolute value. Always forget that CLI usage is much wider than i expect |
however, for example, for |
|
i'd make it simple - for each command with expiration context:
P.S. for tokens, only |
dcd903a to
80eaaa3
Compare
| ni, err := internalclient.NetworkInfo(ctx, netInfoPrm) | ||
| common.ExitOnErr(cmd, "can't get current epoch: %w", err) | ||
| currEpoch := ni.NetworkInfo().CurrentEpoch() | ||
| lifetime = exp - currEpoch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think i would be better to change CreateSession definition cause you do NetworkInfo here to do NetworkInfo one more time inside CreateSession later
or at least check that exp > currEpoch
| flags.StringP(commonflags.Account, commonflags.AccountShorthand, commonflags.AccountDefault, commonflags.AccountUsage) | ||
| flags.String(outFlag, "", "File to write session token to") | ||
| flags.Bool(jsonFlag, false, "Output token in JSON") | ||
| flags.StringP(commonflags.RPC, commonflags.RPCShorthand, commonflags.RPCDefault, commonflags.RPCUsage) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated as well.
|
BTW, @roman-khimov, @vvarg229, @evgeniiz321 some issues for testing it? |
46a7b6e to
3f220e2
Compare
aa6d58f to
7fda793
Compare
7fda793 to
9b2edf7
Compare
9b2edf7 to
df0933c
Compare
df0933c to
0223d14
Compare
|
Requires a rebase now to solve CHANGELOG conflict. |
cmd/neofs-cli/modules/object/util.go
Outdated
| currEpoch, err := internal.GetCurrentEpoch(ctx, endpoint) | ||
| common.ExitOnErr(cmd, "can't fetch current epoch: %w", err) | ||
| exp := currEpoch + sessionLifetime | ||
| tok.SetNbf(currEpoch) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, i see, some my suggestion conflicts with the reallity. i would not set some parts of a token here and some on the CreateSession side cause it bug-prone IMO
can we pass currEpoch as a param instead? or any another alternative that does not make a caller set nbf and iat outside?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, we can (made it in the last commit), however, actually it seems that at the beginning (#2521 (comment)) when we were passing lifetime to the CreateSession it was more optimal in numbers of calls of internal.GetCurrentEpoch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
up to you then. i just did not like expireAt = expireAt - currEpoch + currEpoch before. making one more method for expireAt case is also ok to me. getting epoch num before every CreateSession too
Refactor CLI usage to standardize the expired-at flag and lifetime flag. This change is aimed at preventing confusion during flag interpretation and empowering users. Closes #1574. Signed-off-by: Ekaterina Pavlova <[email protected]>
0223d14 to
3b463c0
Compare
The expired-at flag replaces the deprecated lifetime flag.
Closes #1574.