-
Notifications
You must be signed in to change notification settings - Fork 107
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
Restorer changes for run image extension #1014
Conversation
- The logic to update the default path for TOML files was repeated across phases - In general it is safe to provide default values for inputs that might not be relevant to the current phase, as these will be ignored when constructing a new service for the phase; e.g., platform.LifecycleInputs.OrderPath will be ignored when constructing a lifecycle.Exporter - As more inputs are shared across phases (e.g., analyzed.toml is now an input to the detect phase), duplicating the logic for providing default values is becoming more cumbersome Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
…= 0.10 Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
…kage Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
… the platform spec Signed-off-by: Natalie Arellano <narellano@vmware.com>
…mage.extend = <true or false, default false> Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
… should fail if the selected base image is not found in run.toml. Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Still needs to add target data; blocking on #994 |
fa89581
to
53dbf59
Compare
- digest ref for run image - target data for run image Additionally the restorer will download the run image manifest & config when extend is true Signed-off-by: Natalie Arellano <narellano@vmware.com>
53dbf59
to
62411e8
Compare
Signed-off-by: Natalie Arellano <narellano@vmware.com>
imgutil/layout/sparse modifies the image media types which we don't want Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
This will be easier to review as a diff on top of |
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Still need to bring this up-to-date with main (hence the huge diff) |
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
cmd/lifecycle/restorer.go
Outdated
} | ||
buildImageHash, err := remoteImage.Digest() | ||
// get remote image | ||
remoteImage, digest, err := newRemoteImage(imageRef, r.keychain) |
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.
If exporting to layout format we could look for the run image in the layout directory, but since the pack implementation currently requires the builder to exist in a registry (even when exporting to a daemon) we could keep this requirement for the run image and drop it whenever buildpacks/pack#1623 is completed.
platform/run_image.go
Outdated
) | ||
|
||
type TargetMetadata struct { | ||
ID string `toml:"id"` |
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.
heh -- i also just added this ID Field. but i think here you got rid of that "partial" struct i was playing with... pros and cons, but now it's decoupled from what happens in the buildpack side, which imo was the only value of that partial (to preserve & codify the coupling). I thought it was correct to keep them coupled (and add the ID field to both structs) but if we're not doing that then it's probably correct to delete the TargetPartial struct entirely from bp_descriptor.go.
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 removed it just because it's simpler, but if we find we need it, we can put it back.
platform/run_image.go
Outdated
Distribution *OSDistribution `toml:"distribution"` | ||
} | ||
|
||
type OSDistribution struct { |
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.
here too -- what's your guidance on de/coupling with the bp_descriptor.go file? My gut still says that they're reading & writing the same things, so it's better to have them using the same structs. But I also think it's somewhere between possible and likely that I'm missing something..
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.
In this case the platform spec and the buildpack spec happen to match each other (and happily so), but there isn't any technical reason that they are tied together. By contrast where for example platform.BuildMetadata
depends on buildpack.Label
that schema is directly coming from the buildpack spec and how buildpacks define labels. At least, that is my rationalization.
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Let's block this on #1030 as the changes from that PR will be useful here |
We'll be able to fully remove internal/selective when we update tests for the extender as part of #998 Signed-off-by: Natalie Arellano <narellano@vmware.com>
Ensure we write a digest reference to analyzed.toml Signed-off-by: Natalie Arellano <narellano@vmware.com>
cmd/lifecycle/exporter.go
Outdated
@@ -64,12 +64,12 @@ func (e *exportCmd) DefineFlags() { | |||
cli.FlagProcessType(&e.DefaultProcessType) | |||
cli.FlagProjectMetadataPath(&e.ProjectMetadataPath) | |||
cli.FlagReportPath(&e.ReportPath) | |||
cli.FlagRunImage(&e.RunImageRef) | |||
cli.FlagRunImage(&e.RunImageRef) // Note: this flag isn't valid on Platform 0.7 and later, and any provided value is ignored |
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.
cli.FlagRunImage(&e.RunImageRef) // Note: this flag isn't valid on Platform 0.7 and later, and any provided value is ignored | |
cli.FlagRunImage(&e.RunImageRef) // Note: this flag isn't valid on Platform 0.7 and later |
(randomly found when reviewing the code) Actually, I don't think we even ignore the provided value :/ we should probably change this, especially when we formally deprecate platforms older than 0.7
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.
wait what does that mean, that it's not valid but "we don't even ignore the provided value" -- what do we do with it?
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 flag was supposed to have been removed from the exporter when we released Platform API 0.7. But, it looks like we forgot :( When I added the above comment I thought we ignored the provided value but we don't, we use it to construct the exported image. We could just remove it and "fix" the lifecycle but I worry that platforms may be relying on it even if it's not in the spec.
cmd/lifecycle/exporter.go
Outdated
cli.FlagStackPath(&e.StackPath) | ||
cli.FlagUID(&e.UID) | ||
cli.FlagUseDaemon(&e.UseDaemon) | ||
|
||
cli.DeprecatedFlagRunImage(&e.DeprecatedRunImageRef) | ||
cli.DeprecatedFlagRunImage(&e.DeprecatedRunImageRef) // Note: this flag isn't valid on Platform 0.7 and later, and any provided value is ignored |
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.
cli.DeprecatedFlagRunImage(&e.DeprecatedRunImageRef) // Note: this flag isn't valid on Platform 0.7 and later, and any provided value is ignored | |
cli.DeprecatedFlagRunImage(&e.DeprecatedRunImageRef) // Note: this flag isn't valid on Platform 0.7 and later |
@@ -89,40 +102,6 @@ func (t *TargetMetadata) IsSatisfiedBy(o *buildpack.TargetMetadata) bool { | |||
return true | |||
} | |||
|
|||
func GetTargetFromImage(image imgutil.Image) (*TargetMetadata, 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.
Moved to run_image.go
@jabrown85 @joe-kimmel-vmw I think this is ready for one more look |
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 - left a couple small questions but no blockers, mostly just my own confusion :)
// Values from image acceptance/testdata/exporter/container/layout-repo in OCI layout format | ||
analyzedMD.RunImage = &platform.RunImage{ | ||
Reference: "/layout-repo/index.docker.io/library/busybox/latest@sha256:445c45cc89fdeb64b915b77f042e74ab580559b8d0d5ef6950be1c0265834c33", | ||
regPlaceholders := []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.
what do you think about leaving this comment as a //comment
in the code?
@@ -80,7 +82,7 @@ func testRestorerFunc(platformAPI string) func(t *testing.T, when spec.G, it spe | |||
}) | |||
}) | |||
|
|||
when("called with -analyzed", func() { | |||
when("called with -analyzed (on older platforms)", func() { |
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+ update to test descriptions
cmd/lifecycle/exporter.go
Outdated
@@ -64,12 +64,12 @@ func (e *exportCmd) DefineFlags() { | |||
cli.FlagProcessType(&e.DefaultProcessType) | |||
cli.FlagProjectMetadataPath(&e.ProjectMetadataPath) | |||
cli.FlagReportPath(&e.ReportPath) | |||
cli.FlagRunImage(&e.RunImageRef) | |||
cli.FlagRunImage(&e.RunImageRef) // Note: this flag isn't valid on Platform 0.7 and later, and any provided value is ignored |
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.
wait what does that mean, that it's not valid but "we don't even ignore the provided value" -- what do we do with it?
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Fixes #997