-
Notifications
You must be signed in to change notification settings - Fork 54
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
✨unpacker: switch from google/go-containerregistry to containers/image #1194
✨unpacker: switch from google/go-containerregistry to containers/image #1194
Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1194 +/- ##
==========================================
+ Coverage 76.49% 76.82% +0.32%
==========================================
Files 40 40
Lines 2336 2369 +33
==========================================
+ Hits 1787 1820 +33
+ Misses 392 383 -9
- Partials 157 166 +9
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
8222c11
to
6558ab3
Compare
295179a
to
7c8a6e0
Compare
7c8a6e0
to
56d6266
Compare
0145e41
to
df384cd
Compare
df384cd
to
f21e3e5
Compare
@@ -194,14 +195,18 @@ func main() { | |||
setupLog.Error(err, "unable to create CA certificate pool") | |||
os.Exit(1) | |||
} | |||
unpacker := &source.ImageRegistry{ | |||
BaseCachePath: filepath.Join(cachePath, "unpack"), | |||
CertPoolWatcher: certPoolWatcher, |
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.
Loss of CertPoolWatcher: certPoolWatcher
here...
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.
Not seeing ContainersImageRegistry
use certificate, so is the certPoolWatcher even necessary?
And if that's the case, this could lead to more code being deleted... but presumably it's used somewhere?
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.
Yes, in BuildHTTPClient
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.
Yeah, the containers/image source implementation lets us set the CA files on a context struct, which I think are reloaded on every pull.
And yeah, the certPoolWatcher should still be used to connect to catalogd.
f21e3e5
to
19b26b5
Compare
cmd/manager/main.go
Outdated
defaultAuthConfigPath := filepath.Join("/etc", "containers", "auth.json") | ||
if _, err := os.Stat(defaultAuthConfigPath); err == nil { | ||
unpacker.SourceContext.AuthFilePath = defaultAuthConfigPath |
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.
This doesn't seem to be a default for containers/image
, interestingly. Researching this a bit more.
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.
Primary read/write file for auth seems to be ${XDG_RUNTIME_DIR}/containers/auth.json
or $HOME/.config/containers/auth.json
: https://github.com/containers/image/blob/main/docs/containers-auth.json.5.md#description
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.
Looking at this, we should probably revisit the RFC and highlight the default location for all the configs we may care about
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.
So it turns out that file location is just not a thing (yet at least): containers/image#1746
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.
We could follow the pattern that podman and skopeo do. If REGISTRY_AUTH_FILE
is set in the environment, we set its value on this field. I'll switch the PR to do that for now.
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 took all of the auth stuff back out of the PR for now. We should discuss and handle separately.
This PR is now focused on containers/image
and use of /etc/containers
system configuration (as an unsupported/subject-to-change internal API)
ee7fe25
to
1506cea
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.
A few comments. Mostly surrounding the need for a new Issuer?
Makefile
Outdated
|
||
|
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: extra blank line.
CGO_ENABLED=1 go test \ | ||
-tags '$(GO_BUILD_TAGS)' \ | ||
-cover -coverprofile ${ROOT_DIR}/coverage/unit.out \ | ||
-count=1 -race -short \ | ||
$(UNIT_TEST_DIRS) \ | ||
-test.gocoverdir=$(ROOT_DIR)/coverage/unit |
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.
Wondering if you want to go all out and put each flag on its own line?
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 was mainly focused on "like flags" and "can I see it without side-to-side scrolling?"
Notes
- I wanted UNIT_TEST_DIRS as close to the end as possible because I sometimes find myself copying/pasting the command line from a full run so that I can run unit tests in a specific package (and yes, I know we could make
UNIT_TEST_DIRS
overrideable, but in other projects that do that I always forget what the var name is, so I end up copy/pasting anyway) - I was forced to put
test.govoerdir
after the UNIT_TEST_DIRS because those flags are passed to the test binary.
@@ -173,6 +182,7 @@ build-push-e2e-catalog: ## Build the testdata catalog used for e2e tests and pus | |||
test-e2e: KIND_CLUSTER_NAME := operator-controller-e2e | |||
test-e2e: KUSTOMIZE_BUILD_DIR := config/overlays/e2e | |||
test-e2e: GO_BUILD_FLAGS := -cover | |||
test-e2e: E2E_REGISTRY_CERT_REF := Issuer/selfsigned-issuer |
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.
Should this be ClusterIssuer/olmv1-ca
? Did you really want to create another CA/Issuer? Note that we already have a self-signed-issuer
in the cert-manager
namespace.
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.
The intention here is to setup our standard e2e test with:
- an image registry the serves with an untrusted certificate
- a mounted
/etc/containers/registries.conf
file that instructs operator-controller to allow insecure connections to the image registry.
This setup proves that our image puller respect what shows up in /etc/containers/registries.conf
(if the registries.conf
volume mount is removed, the tests fail)
The extension developer e2e and the upgrade e2e are left using the standard olmv1-ca to:
- Verify that op-con works without a mounted /etc/containers/registry.conf
- Avoid issues with pre-upgrade setup which depends on using the unmodified manifest of the previous release (meaning we can't mount
/etc/containers
to allow op-con to trust an insecure registry)
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 honestly don't love the current setup. It seems overly complex and brittle, and I do acknowledge that this PR makes it ever so slightly more complex and brittle.
I'd be in favor of looking at our e2e test code and fixtures holistically in order to do a bit of cleanup and refactoring, but IMO, in a separate PR.
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.
As long as the intent was to have a separate trust chain for the registries, then ok. The current CAs are used for communication catalogd <-> operator-controller, and api-server -> catalogd (for webhooks)
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.
Yes, the intent is to explicitly have a separate (untrusted) trust chain. The other places the CA were used are:
- catalogd -> e2e image registry
- operator-controller -> e2e image registry
Prior to this PR, the same exact image registry setup was used for every e2e (e2e, upgrade-e2e, and developer-extension-e2e).
With this PR, the vanilla e2e is explicitly changed to use the untrusted self-signed cert (while the other e2e variants remain unchanged)
--- | ||
apiVersion: cert-manager.io/v1 | ||
kind: Issuer | ||
metadata: | ||
name: selfsigned-issuer | ||
namespace: ${namespace} | ||
spec: | ||
selfSigned: {} |
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.
Not sure why you want another issuer (a few comments on this)
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.
See #1194 (comment)
type Unrecoverable struct { | ||
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.
Is there an explicit check for this type of 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.
Hmm. It appears that we do not check for this error type in our reconciler. I brought this over from the now-deleted image_registry.go
where it was used.
I do check for it in unit tests.
WDYT about addressing this in a follow-up?
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.
Depends on how many other changes will occur if you update... but at least it's isolated.
config/components/registries-conf/registries_conf_configmap.yaml
Outdated
Show resolved
Hide resolved
Signed-off-by: Joe Lanford <joe.lanford@gmail.com>
1506cea
to
3d14a53
Compare
Signed-off-by: Joe Lanford <joe.lanford@gmail.com>
3d14a53
to
41f0aaf
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.
/lgtm
/hold Adding a hold as @everettraven and me can use few hours to review and test the PR . Will remove the hold before EOD today. |
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
/hold cancel |
097d897
Description
See https://docs.google.com/document/d/1s-nfpJqecWGuriFIVXr2REbZLUB8N8QxLp1MQKLPhlE/edit#heading=h.x3tfh25grvnv
Reviewer Checklist