You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »



Attendees

Walter Kozlowski (Telstra)

Pankaj Goyal (AT&T)

Michael Bustamente (AT&T)

Beth Cohen (Verizon)

MICHAEL FIX (AT&T)

Samuel Hellec (Orange)

Nick Chase (Mirantis)

Mark Shostak (AT&T)

@Tamas Zsiros (Ericsson)

Gergely Csatari (Nokia)

Karine Sevilla (Orange)

Herbert Damker (DT)

Toshiyasu Wakayama (Toshi, KDDI)

Kyle Greenwell (Verizon)

Kodi Atuchukwu

Olaf Renner (Nokia)

Pierre Lynch

Xu Yang

Trevor Cooper

Uli Kleber


Agenda and Minutes:

  1. Continue the discussion we started in Antwerp regarding K8s RA.
  2. There has been great discussion on GitHub within the initial content of K8s RA: https://github.com/cntt-n/CNTT/pull/383
  3. The aim is to continue the discussion and agree on the next step forward. (Terminology, From CaaS -> Infrastructure)


Meeting was devoted to the Containers in general and Kubernetes in particular terminology deep dive discussion.

Several comments were added to the contents of https://github.com/cntt-n/CNTT/pull/383. These plus the following general directions agreed in the meeting need to be addressed by the updates in the document:

  1. Implementation of the run-time needs to be generic.  Hence references to Docker need to be replaced by "container run-time" or equivalent.
  2. CaaS and PaaS definitions need to be taken out of the Table and moved to Introduction, where they need to be properly and precisely defined for the purpose of this RA and diagrammatically illustrated.  Generally we got closer to an agreement about the difference between these two notions but this topic requires further discussion. 
  3.  As note: LCM features are generally lacking form the descriptions.
  4. We have agreed that the definitions should be in principle base don industry standards (and properly referenced), with NOTES added when we need to differ.  We call upon all of us to review these definitions form that point of view.
  5. We decided that the definitions and names used should be as closed to the Kubernetes language as possible.  Also, generic names should have Kubernetes added when appropriate , e.g. it should be Kubernetes cluster, not just cluster which is ambiguous.

Thanks everyone for your contribution!

  • No labels