-
Notifications
You must be signed in to change notification settings - Fork 638
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
Login & authentication rework, part 1: credentials management and URL parsing #3293
Conversation
d0e699e
to
0afef56
Compare
@fahedouch @AkihiroSuda PTAL at your convenience |
cmd/nerdctl/login_linux_test.go
Outdated
) | ||
|
||
func safeRandomString(n int) string { |
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.
Moved to test_registry
Conflict is likely trivial. Will rebase after review, in case there are any comments or concerns to address. |
d50e9da
to
864c5be
Compare
@AkihiroSuda we have regular network related failures on Ubuntu 20.04 / v1.6. Symptom being
We could retry on login for that condition - but I am more interested in fixing the root issue. Do you think this is something in rootlesskit or bypass4netns? |
No, this seems rootful |
Yes, you are right. So, I guess when under pressure (starting / stopping many containers), networking is breaking down or is slow to converge? |
b0d4293
to
996f7c6
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.
Left some early comments. Still have some changes left to be reviewed. thanks
"github.com/containerd/log" | ||
) | ||
|
||
type Credentials = types.AuthConfig |
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.
Suggest change to type AuthConfig = types.AuthConfig
. If we want to have a type alias we should keep the name the same.
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.
Ok.
I guess I do not like AuthConfig
as a name, but that's fine, let's keep it the same.
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.
Actually, do you mind if we keep Credentials
?
AuthConfig
is really a bad name... If anything, it does evoke https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/system-level_authentication_guide/authconfig-install#authconfig-install instead of what it really is... just credentials...
It also "makes sense" that the CredentialsStore
would store Credentials
.
type isFileStore interface { | ||
IsFileStore() bool | ||
GetFilename() string | ||
} |
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.
interface should be moved to the begining of the file, or at least before the implementation.
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.
It is private and only used internally in this file - there is no implementation, as it is used solely to cast docker credentials store.
In that context, do you feel it should still be moved up? (no strong opinion on my side)
var ( | ||
ErrUnableToInstantiate = errors.New("unable to instantiate docker credentials store") | ||
ErrUnableToErase = errors.New("unable to erase credentials") | ||
ErrUnableToStore = errors.New("unable to store credentials") | ||
ErrUnableToRetrieve = errors.New("unable to retrieve credentials") | ||
) | ||
|
||
// Errors returned by `Parse` | ||
var ( | ||
ErrUnparsableURL = errors.New("unparsable registry URL") | ||
ErrUnsupportedScheme = errors.New("unsupported scheme in registry URL") | ||
) |
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.
nit: are they used widely in nerdctl or by downstream? if not I prefer just returning a errors.New(...)
directly when needed instead of predefining them.
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.
nit: are they used widely in nerdctl or by downstream?
Not yet.
The reason I like them is that they allow downstream code to actually test (errors.Is(err, ErrXYZ)
) the error (instead of matching strings, which I find abhorrent...), and allows providing more refined user feedback based on these (or decide to ignore certain errors in certain circumstances).
This of course applies to testing as well (as a nice benefit, where we can actually verify what error is being returned in integration testing without having to duplicate strings again).
LMK if you feel strongly about these and of course open to amending.
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.
Overall motivation for me is that our error-ing is not great right now (see #3302 for example), and that is generally in the codebase.
We tend to just bubble-up system errors that are meaningless or even misleading for the user (#3197) - and at best, makes it hard to pinpoint for us when reading bug reports.
This is obviously a very large endeavor to change this situation overall, and it might take a few iterations to come up with a reasonable set of errors and informative enough wrapping, but I believe it is essential.
Thanks a lot @djdongjin |
Failure are unrelated:
Could we poke the CI to restart these? |
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 probably need more time to review some of the changes, as it's a bit difficut to identify which are logic changes, and which are refactors/code relocation/etc.
Also some suggestions on reducing PR size:
- Add UTs first in a separate PR or commit if UT itself has a lot of changes. If you're trying to fix something and the UT helps reproduce it, you can add and skip that UT (or just add it in a later PR).
- Do refactor or move code around in a separate PR: it's difficult to identify a small change if it's mixed with a refactor.
- You can use tools like https://github.com/modularml/stack-pr to make small PRs and make a big change incrementally.
That is fine.
Will definitely look into stack-pr - great tips, thanks. Let me see if I can massage my two other "big-ish" PRs into something more amenable to review. Meanwhile, we can just stay focused on this one - and also #3362 would be nice to get if you have a minute <- it is a small one! Pinky swear! :-) |
Latest CI fail is the usual Unfortunately, I couldn't figure it out so far (#3305) - it is a massive PITA. Anyone familiar with IPFS around? |
cc @ktock |
@AkihiroSuda could you poke the CI for the flaky IPFS 20.04/1.6 run? |
e2b7f49
to
f16657d
Compare
Rebased. Pending green CI. |
f16657d
to
17b2ad0
Compare
17b2ad0
to
864b432
Compare
Rebased. |
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.
Thanks
Signed-off-by: apostasie <spam_blackhole@farcloser.world>
864b432
to
04cc74b
Compare
Last push just enable the commented out test (see answer in comment about Lima error) |
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.
LGTM, thanks
This is a breakout of #3249 and first part of fixing our credentials management / login issues (see 3249 for details about issues, including #3072 which is the reason a significant rewrite is warranted IMHO).
The focus is this PR is solely:
This does:
expected acArg to be "docker.io", got "registry-1.docker.io"
) #3245 and a number of other oddities (now enshrined in tests)CredentialsStore
andRegistryURL
parsing, and integration testing, which should hopefully give us a much firmer understanding of what is supposed to happen whenWhat this does NOT: