-
Notifications
You must be signed in to change notification settings - Fork 252
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
fix(loader): Image Loader doesn't create the same channel entries as the other loaders. #236
fix(loader): Image Loader doesn't create the same channel entries as the other loaders. #236
Conversation
/retest |
required apis with channel entries, rather than bundles. this trades an additional join at query time for a much simpler load interface
Tested with some real bundles: $ opm index add -c docker -b quay.io/shawn_hurley/testoperator:v1.0.0 --tag quay.io/ecordell/test-index:0
INFO[0000] building the index bundles="[quay.io/shawn_hurley/testoperator:v1.0.0]"
INFO[0000] running docker pull img="quay.io/shawn_hurley/testoperator:v1.0.0"
INFO[0000] running docker save img="quay.io/shawn_hurley/testoperator:v1.0.0"
INFO[0000] loading Bundle quay.io/shawn_hurley/testoperator:v1.0.0 img="quay.io/shawn_hurley/testoperator:v1.0.0"
INFO[0000] found annotations file searching for csv dir=bundle_tmp215707306 file=bundle_tmp215707306/metadata load=annotations
INFO[0000] found csv, loading bundle dir=bundle_tmp215707306 file=bundle_tmp215707306/manifests load=bundle
INFO[0000] loading bundle file dir=bundle_tmp215707306/manifests file=testoperator.v1.0.0.clusterserviceversion.yaml load=bundle name=testoperator.v1.0.0
INFO[0000] Generating dockerfile bundles="[quay.io/shawn_hurley/testoperator:v1.0.0]"
INFO[0000] writing dockerfile: index.Dockerfile857028972 bundles="[quay.io/shawn_hurley/testoperator:v1.0.0]"
INFO[0000] running docker build bundles="[quay.io/shawn_hurley/testoperator:v1.0.0]"
INFO[0000] [docker build -f index.Dockerfile857028972 -t quay.io/ecordell/test-index:0 .] bundles="[quay.io/shawn_hurley/testoperator:v1.0.0]" Channel Entry Table:
Channel Entry table:
|
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.
Looks great!
My primary concern is the TODO
for the migration of bundle image refs; i.e. where do we get replaces/skips since the CSV has been removed for non-channel-head bundles?
This adds an additional test to the imageloader test suite that shows the issue (it fails without the other changes in this commit). The update logic was different from the "new" logic for adding bundles. To simplify reasoning about these two paths, they're now the same - updating will recalculate the graph from the new entrypoints and replace whatever was there before.
requires migrations
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.
Looks great!
/retest |
3 similar comments
/retest |
/retest |
/retest |
return err | ||
}, | ||
Down: func(ctx context.Context, tx *sql.Tx) error { | ||
// TODO |
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.
what happens if the migration fails? should we do anything with this TODO
?
/retest |
Spent a good deal of time going over the PR with @ecordell - thanks for all the insight. Pulling out the skips and replaces (via the new schema updates) and rebuilding the image loader graph for each new bundle will also help with the bundle image commutativity work that we've been looking at @gallettilance @kevinrizza. /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ecordell, exdx, njhale The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
/retest Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
/retest Please review the full test history for this PR and help us cut down flakes. |
This began as an investigation into #205 - odd behavior when adding a new bundle via
index add
The issue there was the image loader was not properly handling the case (as described in #205) where a new bundle being added both replaces something in an existing channel, and starts a new channel as well.
I removed the assumption that a
replace
s exists in the current channel, which was enough to prevent the bug in #205. I wrote a test inimage_test.go
to verify the behavior with the new graph representation.That test made me realize that the image loader was not building graphs the same way as the other loaders - because the image loader doesn't synthesize nodes outside the current channel, the graph comes out missing some nodes. In particular, we would fail to answer correctly "does a replacement for X exist in channel A" even if there is an operator in channel A with a replaces field that says X.
The fact that the behaviors diverge at all is somewhat concerning, so I looked at what it would take to have the image loader and the other loaders share the same graph building implementation. There were two blockers:
replaces
field, which is not always present anymore when using bundle images.I started by addressing those two things:
Follow up work:
There should be some indication that the migration may be incomplete if bundlepaths are used. I think this is somewhat okay at the moment because there are not a lot of bundle images being used. But existing indexes would need to
rm
the package and re-add all of the bundle images so that the replaces/skips fields are unpacked correctly. We should have some standard way to handle this going forward and surface options to the user for whether they want bundle pulls to occur for migrations.Reviewer Checklist
/docs