Labels and extension meta data in containers

[klizhentas]

I would like to discuss ability to attach application-specific meta data to container images. Here are a couple of examples that come to mind:

• bookeeping of versions of libraries included in the image that can be later inspected by security audit tools to update containers with obsolete/vulnerable libraries
• adding application-specific information that can be used by implementation to execute custom actions, e.g. host restrictions (this container can only run on a host with > 60 GB or RAM)
• adding custom signatures to the app-specific content in the image

For example, app container spec adresses this use-case by introducing labels:

labels (list of objects, optional) used during image discovery and dependency resolution. The listed objects must have two key-value pairs: name is restricted to the AC Identifier formatting and value is an arbitrary string. Label names must be unique within the list, and (to avoid confusion with the image's name) cannot be "name". Several well-known labels are defined:
version when combined with "name", this SHOULD be unique for every build of an app (on a given "os"/"arch" combination).
os, arch can together be considered to describe the syscall ABI this image requires. arch is meaningful only if os is provided. If one or both values are not provided, the image is assumed to be OS- and/or architecture-independent. Currently supported combinations are listed in the types.ValidOSArch variable, which can be updated by an implementation that supports other combinations. The combinations whitelisted by default are (in format os/arch): linux/amd64, linux/i386, freebsd/amd64, freebsd/i386, freebsd/arm, darwin/x86_64, darwin/i386. See the Operating System spec for the environment apps can expect to run in given a known os label.

After trying to use labels in practice, I can say that ACI's labels have the following limitations:

• Value of the label is limited to string, what makes it hard to include structured data in the value
• Label names are unique, but not enforced in the data structure that is presented as a list.

The useful part about labels is namespaces, that helps to identify the purpose of meta data and avoid collisions.

It would be very helpful to include the mechanism of adding meta data to the open container images that addresses some of the limitations listed above.

[klizhentas]

Some additional discussion can be found here:

• https://groups.google.com/a/opencontainers.org/d/msg/dev/RF6qm-75IJ0/Jcz-CC_2DwAJ
• https://groups.google.com/a/opencontainers.org/d/msg/dev/RF6qm-75IJ0/5zZ7VM73DwAJ

[wking]

I second Solomon 1 in feeling like this is a useful feature, but
separate enough from “launching a container” to be worth keeping in a
separate place. Can't folks who want labels just put them in
label.json (or wherever they like) in the bundle?

.
├── config.json
├── label.json
└── rootfs

 From: Solomon Hykes
 Subject: Re: Open Container Weekly Meeting - Aug 12, 2015
 Date: Tue, 11 Aug 2015 12:40:58 -0700
 Message-ID: <CACfVideh885xs6E9vs37xGWdnJ77rY48z2qwoiOncWE8D++iXw@mail.gmail.com>
 Cc: dev <[email protected]>, …

[philips]

@wking FYI, we have decided to use the mailing list for discussion of features that don't exist yet.

[wking]

On Tue, Aug 11, 2015 at 03:44:07PM -0700, Brandon Philips wrote:

@wking FYI, we have decided to use the mailing list for discussion
of features that don't exist yet.

Right, sorry. It may take me a few iterations to break my fingers ;).
This discussion has moved to 1.

 From: Alexander Klizhentas
 Subject: Labels and extension meta data in containers #108
 Date: Tue, 11 Aug 2015 14:14:04 -0700
 Message-ID: <CAEMTkLbqUhyY97iPZ3_4axJ3yUwX9oOVOnQQr_Ks_aRr8R-1mg@mail.gmail.com>
 To: dev <[email protected]>