• Type: Task
    • Status: Resolved
    • Priority: Medium
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: Marathon 1.4.0
    • Component/s: None
    • Labels:


      there's actually some wacky things that happen with labels for pods when Marathon generates the protobufs for Mesos to consume:

      (1) appc image labels are built from Marathon API container image labels + container labels + pod labels
      (2) task labels are built from Marathon API container labels
      (3) executor labels are built from Marathon API pod labels
      (4) command info envvars are augmented with vars generated from labels (we do this for apps too), and for pods the labels are sourced from Marathon API pod + container
      (5) network labels are propagated from Marathon API to Mesos network-infos
      (6) port labels are propagated from Marathon API to Mesos task DI port labels

      There's some behavioral bugs up there. I'd suggest the following changes:

      (a) appc image labels should probably not be sourced from the API container + pod labels as in (1); we're actually missing Marathon API image labels in our RAML spec/model (because this is ideally where the appc image labels should be sourced from); also, we should document the default labels that Marathon injects for appc image protobufs (os -> linux, arch -> amd64 (these should be overridable by Marathon API image labels)).

      (b) the behavior of (4) implies that the behavior of (2) is incorrect; (2) should also incorporate pod labels (this would be consistent w/ how envvars declared at the API pod level are copied to all subtasks)




            • Assignee:
              jdef James DeFelice
              jdef James DeFelice
              ( DO NOT USE ) Orchestration Team
            • Watchers:
              0 Start watching this issue


              • Created: