-
Notifications
You must be signed in to change notification settings - Fork 38
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
cli: unify usage of expired-at flag instead of lifetime flag #2521
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
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.