Skip to content
This repository has been archived by the owner on Jun 18, 2020. It is now read-only.

As an app developer, pack rebase automatically determines a run image using the available mirrors #48

Closed
ekcasey opened this issue Jan 31, 2019 · 9 comments
Assignees

Comments

@ekcasey
Copy link
Member

ekcasey commented Jan 31, 2019

Acceptance Criteria
Given
When I run pack build my-image
Then I new version of the run image is available on all mirrors

Scenario 1
When I run pack rebase my-image (without --run-image)
Then The run image under my-image is replaced with a run image from the appropriate source

Scenario 2
When I run pack rebase my-image --run-image custom/image
Then The run image under my-image is replaced with custom/image

Notes

  • Mirror selection for the run image should use the same order as pack build. This means the run-image and run-image-mirrors from the builder used during pack build must be encoded in the generated OCI image on each pack build.
  • Update pack README to describe new model
  • Don't fail when a builder or stack image cannot be pulled pack#90 covers updating --no-pull to work when only a local image is available
  • As with pack build --publish, pack rebase --publish should work when the run image is not available at the target registry. This means that if a suitable run image is not available on the registry, then select the canonical image.
  • Remove pack *-stack commands

Implementation Notes

  • Pack CLI should select run image from list of mirrors
  • pack create-builder should add a file (similar to order.toml) that also contains the run image mirror metadata (that is also available as a LABEL on the image). The file path should have a default value, but also be overridable using an arg or env var (like order.toml).
  • CNB_MIRRORS_PATH / -mirrors / /buildpacks/mirrors.toml
@ekcasey ekcasey created this issue from a note in Planning Board (Backlog) Jan 31, 2019
@ekcasey
Copy link
Member Author

ekcasey commented Jan 31, 2019

@sclevine

@sclevine
Copy link
Member

sclevine commented Feb 3, 2019

Added acceptance criteria and notes.

@sclevine sclevine changed the title pack rebase with run-image mirrors As an app developer, pack rebase automatically determines a run image using the available mirrors on pack rebase Feb 3, 2019
@sclevine sclevine changed the title As an app developer, pack rebase automatically determines a run image using the available mirrors on pack rebase As an app developer, pack rebase automatically determines a run image using the available mirrors Feb 3, 2019
@sclevine sclevine added the size/3 label Feb 4, 2019
@djoyahoy djoyahoy moved this from Backlog to In Progress in Planning Board Feb 27, 2019
@djoyahoy
Copy link
Member

djoyahoy commented Mar 1, 2019

After a team discussion, we want to change this feature to have the following behavior:

Build

  • If the run-image used during build is not from the local config then include the run-image name as a label in the resulting app image.
  • If the run-image used during build is from the local config then do not include the run-image name as a label in the resulting app image.

Rebase

  • If the app image does have a run-image name in a label, use that for the rebase (Scenario 1).
  • If the app image does not have a run-image name in a label, require the user to specify a run-image with the --run-image flag (Scenario 2).

@thisisnotashwin
Copy link
Member

Waiting on approval of buildpacks/lifecycle#90

pack changes on branch run_images_during_rebase to get merged after the above PR is merged

@thisisnotashwin thisisnotashwin moved this from In Progress to Done in Planning Board Mar 5, 2019
@ekcasey
Copy link
Member Author

ekcasey commented Mar 7, 2019

I think the desired end state we would like to get to is the following

pack create-builder

When the builder.toml has the following contents

[stack]
id = "com.example.stack"
build-image = "example/build"
run-image = "example/run"
run-image-mirrors = ["registry.example.com/exmaple/run", "other.example.com/other/run"]

Then the builder is created with a label io.buildpacks.builder.metadata with the following value

"{"runImage":{"image":"example/run","mirrors":["registry.example.com/exmaple/run", "other.example.com/other/run"]}"

And the following file is added to the builder image at path /buildpacks/mirrors.toml.
And the following environment variable is set on the builder image CNB_MIRRORS_PATH=/buildpacks/mirrors.toml

lifecycle/exporter

Scenario 1 (default)

When exporter is called w/o the -runImage flag
Then the exporter selects the right run image from the mirrors.toml file at CNB_MIRRORS_PATH
And all the of the mirrors from the mirrors.toml file are add to the io.buildpacks.run-image.metadata label

"{"runImage":{"image":"example/run","mirrors":["registry.example.com/exmaple/run", "other.example.com/other/run"]}"

Scenario 2 (-runImage)

When exporter is called with the -runImage
Then it uses the provided run-image as the base image for the exported app
And the mirrors from mirrors.toml are added to a label as described above
**The value passed to -runImage does not end up in a label

Scenarios 3 & 4 (-mirrors)

When exporter is called with -mirrors=/some/path/mirrors.toml either with or without -runImage
Then It behaves as described in scenarios 1 (without -runImage) & 2 (with -runImage) but the mirrors.toml is found at /some/path/mirrors.toml is used instead of the file found at CNB_MIRRORS_PATH

pack rebase

pack rebase selects the correct run image from the io.buildpacks.run-image.metadata label

Comments

I am comfortable with us doing some subset of this functionality now but I think the interim behavior the subset to conform to the same interface (lifecycle flag, label names, value names within the labels), requiring only additive changes in the future.

@ekcasey ekcasey added the reject label Mar 7, 2019
@ekcasey ekcasey moved this from Done to Backlog in Planning Board Mar 7, 2019
@djoyahoy
Copy link
Member

With the above the changes, we should revert the change that added the label flag to the exporter.

@djoyahoy djoyahoy moved this from Backlog to In Progress in Planning Board Mar 22, 2019
@sclevine
Copy link
Member

mirrors.toml

image = "string"
mirrors = ["string"]

ekcasey pushed a commit to buildpacks/pack that referenced this issue Mar 27, 2019
* create-builder writes stack.toml with run image and mirrors metadata

[buildpacks/roadmap#48]

Signed-off-by: Danny Joyce <djoyce@pivotal.io>
Signed-off-by: Andrew Meyer <ameyer@pivotal.io>
Signed-off-by: Emily Casey <ecasey@pivotal.io>
@ekcasey ekcasey moved this from In Progress to Done in Planning Board Mar 28, 2019
@ekcasey
Copy link
Member Author

ekcasey commented Apr 2, 2019

We broke out the exporter selecting the run-image into buildpack/roadmap#58

We also made some last minute changes to the schema of metadata labels and files to reduce the total number of labels and the number of different names we use for the same concept

on the builder image:

  1. we created a stack.toml file with the following schema
[run-image]
  image = "string"
  mirrors = ["string", "string"]
  1. we added the stack image to the io.buildpacks.builder.metadata label
{"stack":{"runImage": {"image": "string", "mirrors": ["string", "string"]}}}

on the app image:
we added the stack info to theio.buildpacks.lifecycle.metadata label

{"stack":{"runImage": {"image": "string", "mirrors": ["string", "string"]}}}

@sclevine
Copy link
Member

sclevine commented Apr 3, 2019

Leaving this as unaccepted because I want to test more edge cases, but it looks good enough to release in v0.1.0.

@sclevine sclevine closed this as completed Apr 3, 2019
@ekcasey ekcasey moved this from Done to Release v0.1.0 in Planning Board Apr 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants