[ https://issues.apache.org/jira/browse/MESOS-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14644444#comment-14644444 ]
James DeFelice edited comment on MESOS-2841 at 7/28/15 2:32 PM: ---------------------------------------------------------------- The addition of a Labels field should be just fine for my primary use case (mesos-dns plugin for k8s). It sounds like [~BenWhitehead] wanted something a bit more dynamic and perhaps a structure that is more rich (had suggested "capabilities"). Has there been any thinking around updating/patching FrameworkInfo metadata when a scheduler wants to change what's advertised? I think I ended up with the Meta-based proposal to try incorporating (a) an envelope for shared data, as per [~nnielsen]; (b) supports alternate implementations in the future (generic vs. something more rich); (c) an initial implementation (generic) that provided the simple Labels that I need. I don't want to over-engineer anything. Just trying to find a level of abstraction that balanced concerns. was (Author: jdef): The addition of a Labels field should be just fine for my primary use case (mesos-dns plugin for k8s). It sounds like [~BenWhitehead] wanted something a bit more dynamic and perhaps a structure that is more rich (had suggested "capabilities"). Has there been anything thinking around updating/patching FrameworkInfo metadata when a scheduler wants to change what's advertised? I think I ended up with the Meta-based proposal to try incorporating (a) an envelope for shared data, as per [~nnielsen]; (b) supports alternate implementations in the future (generic vs. something more rich); (c) an initial implementation (generic) that provided the simple Labels that I need. I don't want to over-engineer anything. Just trying to find a level of abstraction that balanced concerns. > FrameworkInfo should include a Labels field to support arbitrary, lightweight > metadata > -------------------------------------------------------------------------------------- > > Key: MESOS-2841 > URL: https://issues.apache.org/jira/browse/MESOS-2841 > Project: Mesos > Issue Type: Improvement > Reporter: James DeFelice > Assignee: Neil Conway > Labels: mesosphere > > A framework instance may offer specific capabilities to the cluster: storage, > smartly-balanced request handling across deployed tasks, access to 3rd party > services outside of the cluster, etc. These capabilities may or may not be > utilized by all, or even most mesos clusters. However, it should be possible > for processes running in the cluster to discover capabilities or features of > frameworks in order to achieve a higher level of functionality and a more > seamless integration experience across the cluster. > A rich discovery API attached to the FrameworkInfo could result in some form > of early lock-in: there are probably many ways to realize cross-framework > integration and external services integration that we haven't considered yet. > Rather than over-specify a discovery info message type at the framework level > I think FrameworkInfo should expose a **very generic** way to supply metadata > for interested consumers (other processes, tasks, etc). > Adding a Labels field to FrameworkInfo reuses an existing message type and > seems to fit well with the overall intent: attaching generic metadata to a > framework instance. These labels should be visible when querying a mesos > master's state.json endpoint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)