Proposal: Initial images proposal

This is a proposal to add a higher level image component that can keep track of Docker image repositories, images, and image metadata.
Will RiderOwner and Head Trainer of PDPTwww.purededicationtraining.com On Tue, Sep 2, 2014 at 4:35 PM,  GoogleCloudPlatform/kubernetes <reply@reply.github.com> wrote:            In docs/images.md:
> @@ -0,0 +1,113 @@
> +# Kubernetes Proposal - Images
> +## Problem/Rationale
> +Kubernetes creates Docker containers from images stored in Docker registries. It does not currently track and store any information about images; it merely pulls and stores them locally on a minion as part of the pod creation process.
> +
> +Adding information related to images - image repositories, the images themselves, tags, and metadata - as resources in an image component will provide foundational support for several use cases, listed below.
> +
> +### Use case: build downstream images when an upstream image repository changes
> +- Add ability to watch an image repository and be notified when changes occur
> +- Another component could automatically rebuild your image after an upstream change
> +- Being able to identify the important resource to watch without having to configure the remote system to notify you of changes is a valuable abstraction
> +
> +**Example**: You create a new image based on SomeUser/AwesomeImage:latest. When the “latest” upstream tag is updated to point at a new image ID, you may want to be notified of the upstream change, and/or have your downstream image automatically rebuilt in response to the upstream update.

This particular example is talking about builds, and not deployments per se. In a PaaS you may want to auto-build and maybe even auto-deploy when new images are added to the registry (with both actions being configurable).

—Reply to this email directly or view it on GitHub.