You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SOCI snapshotter's authorization setup is not immediately obvious. It doesn't share authorization with the containerd client that normally performs a pull and instead relies on either docker credentials or kubernetes credentials. Both require additional setup when using SOCI with private images.
The only documentation we have is to do sudo docker login in our getting started doc which is not realistic in a production environment. Additionally, since SOCI tries hard not to fail an image pull, if it doesn't have credentials it will fall back to pulling with the client which will likely succeed. This leads to confusion about SOCI's performance being on-par or worse than without because it's doing work and then doing a normal image pull anyway.
Describe the solution you'd like
[ ] A doc outlining the authorization options and their configuration
[ ] Update to debug.md to include looking for authorization errors when the SOCI performs worse than ahead-of-time pulls
Describe any alternative solutions/features you've considered
N/A
Any additional context or information about the feature request
Description
The SOCI snapshotter's authorization setup is not immediately obvious. It doesn't share authorization with the containerd client that normally performs a pull and instead relies on either docker credentials or kubernetes credentials. Both require additional setup when using SOCI with private images.
The only documentation we have is to do
sudo docker login
in our getting started doc which is not realistic in a production environment. Additionally, since SOCI tries hard not to fail an image pull, if it doesn't have credentials it will fall back to pulling with the client which will likely succeed. This leads to confusion about SOCI's performance being on-par or worse than without because it's doing work and then doing a normal image pull anyway.Describe the solution you'd like
[ ] A doc outlining the authorization options and their configuration
[ ] Update to debug.md to include looking for authorization errors when the SOCI performs worse than ahead-of-time pulls
Describe any alternative solutions/features you've considered
N/A
Any additional context or information about the feature request
#642 (reply in thread)
The text was updated successfully, but these errors were encountered: