MeetingMinutes: 2015 09 02

Home ▸ MeetingMinutes:

Discussion w/ Video:

Video at https://bluejeans.com/1771332256/

Topics:

• Carried Over:
  • Bundle policies https://github.com/opencontainers/specs/pull/107 (Trevor King)
  • Compliant command line API (Trevor King and Julz Friedman)
  • Split up config.json and runtime.json (Julz, et al)
• Outstanding PRs
  • https://github.com/opencontainers/specs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc (if possible would like to prioritize https://github.com/opencontainers/specs/pull/87 as it is blocking the completion of hooks work)
• Releasing the draft

Attendees:

• Abhijeeth Nuthan
• Alexander Morosov
• Brandon Philips
• Daniel Dao
• Doug Davis
• Jesse Butler
• Joe Beda
• Julz Friedman
• Liangchenye
• Michael Crosby
• Mrunal Patel
• Phil Estes
• Rob Dolin
• Rohit Jnagal
• Trevor King
• Vincent Batts
• Vishnu Kannan
• Will Pragnell

Minutes:

• Bundle policies https://github.com/opencontainers/specs/pull/107
  • language around when launching an application from a bundle, the default is for creating namespaces. Perhaps, like exec into an existing container, there is a use case of having a side-car container (e.g. emacs, gdb) and using another application’s runtime.json
  • What piece of this is missing?
  • Reaping stray child pids from a container. Perhaps using sub-cgroups for a container.
  • Way to specify cgroups paths for launching an application from a bundle.
  • This requires cgroups support in now. Mrunal to take point on this.
  • bundles are an application. Rather than having a number of config’s that are included in that bundle, for multiple applications that are intended to run together.
  • This is either hinging on a “pod”-like semantic for multiple applications that are to run together in a shared host namespaces and resources groups.
  • Or this is hinging on a relationship between the bundles that needs naming and namespaces of bundles, so that these dependencies can be resolved for these separately distributed bundles can be run together.
• Compliant command line API (Trevor King and Julz Friedman)
  • this is for consistent experience of return codes, flags etc.
  • for future implementations (solaris, freebsd, etc)
  • defining requirements first, then the implementations should come from that
  • clarity is needed around https://github.com/opencontainers/specs#1-standard-operations and https://github.com/opencontainers/specs/blob/d83516ef6c2e1a5fee144e39b01103fdf451b937/lifecycle.md#lifecycle and from OCI charter ( https://www.opencontainers.org/charter/ ): “The TDC will look to agree on a standard set of container actions (e.g. start, exec, pause) as well as runtime environment associated with the container runtime”. (duglin) What is the entity on which these operations are defined? Are we just saying that the spec will say “there is a pause operation” and that’s it, or does the spec say “there is a pause operation on XXX and it is invoked by doing YYY”.
• https://github.com/opencontainers/specs/pull/87
  • ship it!
  • michael to do things
• Split up config.json and runtime.json (Julz, et al)
  • pulling out OS specific stuff; separating out the process bit, so that a bundle can piggyback on another application’s process information
  • further is dependent on the progress of breaking out state
  • (crosbymichael) lets be conservative on having a number of jsons shipped in a bundle
  • revisit after state. future concern of readability
• draft release
  • definitely a pre v1.0
  • put together a doc/wiki with milestones for a v1.0
  • (mrunal) lets get state in, then call it v0.1 ?
  • (philips) and https://github.com/opencontainers/specs/issues/95
  • vbatts to take point on starting a wiki doc for draft release and github labels to correspond
  • v0.1 by next discussion (2015-09-09)

Next Meeting: