[ 
https://issues.apache.org/jira/browse/MESOS-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590162#comment-14590162
 ] 

Ben Whitehead commented on MESOS-2841:
--------------------------------------

Ah, missed the {{uri}} vs {{url}} subtlety. Read Endpoint and though URL.

URN is interesting, though looking at the examples you've show each of the 
scenarios looks like a new message type to me. I think mesos has taken the 
approach of specific message types rather than abstract URNs for representing 
things.

For example
{code}
// define a storage driver
storageResource = mesos.Storage{
  acl: {
    visibility: Mesos,
    role: '*'
  },
  version: "v1.*"
}

// define an API resource
apiResource = mesos.HttpResource{
  acl: {
    visibility: Cluster,
    role: '*'
  },
  version: "v1",
  name: "api",
  // declare where the api is accessible
  locations: [
    "http://<host1>:<port>/service/api",
    "http://<host2>:<port>/service/api"
  ]
}
{code}

Even with this view for me, perhaps I'm completely missing your intention, and 
you're trying to get a struct/message into mesos that doesn't have a complex 
structure so that you can do with it what you need to without mesos having to 
be updated.  I can see how this would make things faster to get going, but I'm 
leery of its long term effects.  Perhaps having an unstructured option can help 
us flush out use cases people have for wanting to advertise things.  If that's 
the case {{DiscoveryInfo}} already has 
[{{Labels}}|https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L1260]
 as one of it's properties. I would argue that adding the ability for a 
framework to add/configure {{DiscoveryInfo}}s for itself independent of 
executors/tasks.  This would allow for replacement of {{webui_url}} and 
definitely help with frameworks that want to advertise multiple things, or 
things that aren't UIs.

> 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: Epic
>            Reporter: James DeFelice
>              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)

Reply via email to