WIP: tighten identifier spec 

DO NOT MERGE YET

There are still a couple open questions.  As I read through it I wanted to wordsmith a bit, which lead to reordering some to read sort of top-down.  There were a couple things I thought were wrong (pod name should be a subdomain) and a few things I think we can make more concise.  I also added examples and clarifies corollaries.

@smarterclayton in particular


This became a bit of a thought experiment...

The pod ID is a UUID, right?  so we would end up with:

namespace = k8s.example.com
user-provided pod name = guestbook.thockin
user-provided container name = frontend
apiserver uuid = 01234567-89ab-cdef-0123-456789abcdef

kubelet pod name = 01234567-89ab-cdef-0123-456789abcdef.frontend
kubelet uuid = aabbccdd-0011-2233-4455-aabbccdd

docker container name = k8s_aabbccdd-0011-2233-4455-aabbccdd_01234567-89ab-cdef-0123-456789abcdef_frontend_guestbook.thockin_k8s.example.com or something of different arangement but equal length

Doesn't that feel ... excessive?  The name is already "guaranteed" unique by the kubelet's UUID.  If we embed the master's ID into the name string it becomes opaque to kubelet, so we can't really extract it, which means it is unfit for any purpose other than logging.

Let's look at what values we *might* need again.

The apiserver wants a ID so it can unambiguously report information about a pod instance. That UUID persists across migrations, stop/start cycles, etc.  Call this POD_ID.

The apiserver wants an ID that persists across migrations, but changes on stop/start cycles (e.g. if a minion drops off the network, the scheduler logically stops the pod and moves it to a new minion, then the first minion comes up - they have to have different <something>).  I think we missed this before.  Call this POD_GENERATION.

The apiserver wants an ID that changes every time the pod starts, even on migrations.   This is the kubelet-assigned ID we described.  Call this POD_INSTANCE_ID.

The replication controller wants an ID that is unique for each replica.  Call this POD_REPLICA_ID

The kubelet wants an ID that is assigned when a pod starts on a kubelet.  This is the same as POD_INSTANCE_ID.

Do we need all of these?  I can see use cases for all of them.  Do we want to embed them into name strings, or should we just call them identifiers?  Given that we are trying to avoid writing a checkpoint file, we can embed them into the docker container name.

name=<POD_INSTANCE_ID>_<POD_GENERATION>_<CTR_NAME>_<POD_NAME>_<POD_NAMESPACE>_<POD_ID>

I figure replication probably SHOULD be opaque, so replica controller would embed something into POD_NAME.  E.g. user says PodTemplate.Name = "guestbook" which becomes something like "fd3e.guestbook"

Brian had a sort of awful/awesome idea - we could define these as env variables.  

name=<POD_INSTANCE_ID>_<CTR_NAME>_<POD_NAME>_<POD_NAMESPACE>
env=[
  {name=KUBERNETES_POD_ID, value=...}
  {name=KUBERNETES_POD_GENERATION, value=...}
  {name=KUBERNETES_POD_NAMESPACE, value=...}
  {name=KUBERNETES_POD_NAME, value=...}
  {name=KUBERNETES_CONTAINER_NAME,  value=...}
  {name=KUBERNETES_POD_INSTANCE_ID, value=...}
]

This was sort of an open issue in my summary.  What do you think?  Have I gone off the deep end?

ContainerManifest would end up with:

type ContainerManifest struct {
      MasterID string  // POD_ID, UUID, optional
      Generation int  // POD_GENERATION, optional
      Namespace string // POD_NAMESPACE, DNS_SUBDOMAIN, optional, kubelet can assign
      Name string // POD_NAME, DNS_SUBDOMAIN, see above maybe optional, kubelet can assign
      InstanceID string // POD_INSTANCE_ID, UUID, optional, kubelet can assign
      Containers []Container  // .Name = CONTAINER_NAME, DNS_LABEL, required
}

Can we cut any of those?  I don't see how.  We could maybe drop generation or INSTANCE_ID, but I bet that comes back to bite us.