Skip to content
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

Verify read access while selecting best run-image mirror #1024

Merged

Conversation

pbusko
Copy link
Contributor

@pbusko pbusko commented Feb 28, 2023

Instead of simply picking the first run-image, the lifecycle will select the first accessible reference, if there's no match by registry.

See buildpacks/spec#357

@pbusko pbusko requested a review from a team as a code owner February 28, 2023 15:52
@pbusko pbusko force-pushed the run-image-access-check branch 2 times, most recently from 8fc3d99 to 3c002fb Compare February 28, 2023 15:55
platform/files.go Show resolved Hide resolved
platform/files.go Show resolved Hide resolved
Copy link
Member

@natalieparellano natalieparellano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pbusko thanks for this! I think broadly this PR accomplishes what we want. I'm requesting changes to hopefully align the code with some recently introduced constructs (the image handler) and keep platform.LifecycleInputs scoped to only the things that a platform (operator) would provide. Feel free to offer other suggestions if you think there is a better way to do it.

@natalieparellano
Copy link
Member

@c0d1ngm0nk3y @pbusko apologies for the slow reply (I've been out). I'll have a look at your changes soon.

we are using CheckReadAccess "only" on the run-image and the run-image-mirrors. So shouldn't the export target have nothing to do with that?

If the export target is the daemon, then we also expect to find the run image in a daemon. We don't allow "mixing and matching" although maybe (someday) we should.


type SimpleImageStrategy struct{}

var _ platform.ImageStrategy = &SimpleImageStrategy{}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused - why do we need this global (and why do we override it since it lives on inputs.AccessChecker)?

cmd/lifecycle/analyzer.go Outdated Show resolved Hide resolved
platform/files.go Show resolved Hide resolved

type RemoteImageStrategy struct{}

var _ ImageStrategy = &RemoteImageStrategy{}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious why we need this global

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@natalieparellano Actually, it is used in the main package as well (rebaser.go, analyzer.go)

@c0d1ngm0nk3y c0d1ngm0nk3y force-pushed the run-image-access-check branch 2 times, most recently from d4cf0e6 to 8742299 Compare April 17, 2023 15:09
@c0d1ngm0nk3y
Copy link
Contributor

I'll have a look at your changes soon.

@natalieparellano Did you have a chance to have a closer look? Is something still missing from your side?

@natalieparellano
Copy link
Member

@c0d1ngm0nk3y - many apologies, I missed your comment from 2 weeks ago prodding me to take another look 😞 I'll take a look today

@natalieparellano
Copy link
Member

Looks good @c0d1ngm0nk3y! I think you need to run make lint. The code looks solid - I'm going to follow up on the spec change at Working Group on Thursday (see comment).

@c0d1ngm0nk3y c0d1ngm0nk3y force-pushed the run-image-access-check branch 2 times, most recently from fac4012 to c1256b4 Compare May 3, 2023 06:32
pbusko and others added 2 commits May 8, 2023 15:44
Signed-off-by: Pavel Busko <pavel.busko@sap.com>

Co-authored-by: Ralf Pannemans <ralf.pannemans@sap.com>
Co-authored-by: Johannes Dillmann <j.dillmann@sap.com>

Add unit tests for run image resolution

Co-authored-by: Johannes Dillmann <j.dillmann@sap.com>
Co-authored-by: Philipp Stehle <philipp.stehle@sap.com>
Signed-off-by: Ralf Pannemans <ralf.pannemans@sap.com>

Use ImageStrategy instead of AccessChecker to ease testing

Signed-off-by: Johannes Dillmann <j.dillmann@sap.com>
Signed-off-by: Ralf Pannemans <ralf.pannemans@sap.com>
Co-authored-by: Johannes Dillmann <j.dillmann@sap.com>
Signed-off-by: Johannes Dillmann <j.dillmann@sap.com>
Co-authored-by: Ralf Pannemans <ralf.pannemans@sap.com>
Signed-off-by: Ralf Pannemans <ralf.pannemans@sap.com>
Copy link
Contributor

@c0d1ngm0nk3y c0d1ngm0nk3y left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The acceptance tests failed, so we had to make another small adjustment. Can you check and approve the workflow again?

platform/resolve_inputs.go Show resolved Hide resolved
acceptance/analyzer_test.go Show resolved Hide resolved
Copy link
Contributor

@c0d1ngm0nk3y c0d1ngm0nk3y left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The acceptance tests failed, so we had to make another small adjustment. Can you check and approve the workflow again?

Co-authored-by: Ralf Pannemans <ralf.pannemans@sap.com>
Signed-off-by: Ralf Pannemans <ralf.pannemans@sap.com>
@natalieparellano
Copy link
Member

@c0d1ngm0nk3y @pbusko apologies for the extended back and forth on this one - if you could just pull in https://github.com/buildpacks/lifecycle/pull/1024/files#r1188710899, if the tests all pass then we will merge this in.

@natalieparellano natalieparellano added this to the lifecycle 0.17.0 milestone May 9, 2023
Co-authored-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Ralf Pannemans <ralf.pannemans@googlemail.com>
@c0d1ngm0nk3y
Copy link
Contributor

@natalieparellano There was a small oversight in the test, I fixed that. Sorry. The tests should be fine now.

@@ -20,6 +20,12 @@ var (
)

func ResolveInputs(phase LifecyclePhase, i *LifecycleInputs, logger log.Logger) error {
if i.UseDaemon || i.UseLayout {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is LocalimageStrategy correct for Daemon run images in all cases?

I thought pack build <blah> --publish , for instance, would read the run image from the target registry to place the app layers onto without pulling it down.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, but in the --publish case i.UseDaemon would be false

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to this comment

If the export target is the daemon, then we also expect to find the run image in a daemon. We don't allow "mixing and matching" although maybe (someday) we should.

But does --publish not imply that you export to a registry and not the daemon?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As long as i.UseDaemon is false I think we are good.

@natalieparellano
Copy link
Member

Green! Thanks for the PR @c0d1ngm0nk3y and @pbusko!

@natalieparellano natalieparellano merged commit a2dfc78 into buildpacks:main May 11, 2023
7 checks passed
@pbusko pbusko deleted the run-image-access-check branch May 11, 2023 19:50
@c0d1ngm0nk3y
Copy link
Contributor

@natalieparellano We would really like to consume this change. Do you know what the current plans for release 0.17.0 are?

@natalieparellano
Copy link
Member

@c0d1ngm0nk3y we are getting really close - at this point, we need the specs to be finalized and shipped before we can ship the lifecycle. You can track the progress here: #1165

At this point, I am hoping for a lifecycle 0.17.0-rc.4 early next week, and a lifecycle 0.17.0 late next week. I have a record of being overly optimistic, but I think that's achievable 🙏🏼 🤞🏼

@natalieparellano
Copy link
Member

I am hoping for a lifecycle 0.17.0-rc.4 early next week

I missed the mark by a couple of days, but 0.17.0-rc.4 is out now. If it's possible to try it out and verify that things are still working fine that will help us get the "real" one out sooner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants