[jira] [Comment Edited] (MESOS-3372) Allow mesos agent attributes to be tokenized in taskInfo

["Chad Heuschober (JIRA)" <ji...@apache.org>]

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

Chad Heuschober edited comment on MESOS-3372 at 9/5/15 7:48 PM:
----------------------------------------------------------------

Happy to do so; We have a (docker) application workload that needs to understand its resource locations to make the best possible decisions about where to look for services or data it consumes. Our networking model is calico ip-per-container.

The workload wants to prioritize its service discovery to use a service in the same node followed by rack, then rack pair, then across the dc. Without the ability to inject mesos-agent specific attributes into the taskInfo we have to jump out of the application and either ask the framework to discover or inject this information for us or use a service discovery agent (eg, mesos-dns or mesos-consul) that is, itself, dependent upon parsing what is exposed in `state.json`. We looked at anycast as well but it added too much complexity to the deployment at this time.

While any of the above are options, a framework is a big lift just to give an application its rack awareness and service discovery agents are in a difficult position knowing what should be exposed. Since they don't necessarily know what each workload needs, it feels like that's walking down the road of building a cartesian product of each application and slave attribute and it doesn't do anyone much good to just fork those projects to add the discovery information we want.

It is, in my mind at least, more elegant to allow slave-attributes to be templated into the taskInfo so they can be reused in environment variables or even task configuration scenarios.

I've seen (and please forgive me for not finding it right now) a JIRA issue that essentially requested some agent host information be auto discovered like CPU type, network interface, etc. While it would absolutely be neat to have that auto-discovered, even statically defining such attributes at the agent config and allowing them to be templated into TaskInfo can enable applications to be smarter about using the resources they're on.


was (Author: cheuschober):
Happy to do so; We have a (docker) application workload that needs to understand its resource locations to make the best possible decisions about where to look for services or data it consumes. Our networking model is calico ip-per-container.

The workload wants to prioritize its service discovery to use a service in the same node followed by rack, then rack pair, then across the dc. Without the ability to inject mesos-agent specific attributes into the taskInfo we have to jump out of the application and either ask the framework to discover or inject this information for us or use an service discovery agent (eg, mesos-dns or mesos-consul) that is, itself, dependent upon parsing what is exposed in `state.json`. We looked at anycast as well but it added too much complexity to the deployment at this time.

While any of the above are options, a framework is a big lift just to give an application its rack awareness and service discovery agents are in a difficult position knowing what should be exposed. Since they don't necessarily know what each workload needs, it feels like that's walking down the road of building a cartesian product of each application and slave attribute and it doesn't do anyone much good to just fork those projects to add the discovery information we want.

It is, in my mind at least, more elegant to allow slave-attributes to be templated into the taskInfo so they can be reused in environment variables or even task configuration scenarios.

I've seen (and please forgive me for not finding it right now) a JIRA issue that essentially requested some agent host information be auto discovered like CPU type, network interface, etc. While it would absolutely be neat to have that auto-discovered, even statically defining such attributes at the agent config and allowing them to be templated into TaskInfo can enable applications to be smarter about using the resources they're on.

> Allow mesos agent attributes to be tokenized in taskInfo
> --------------------------------------------------------
>
>                 Key: MESOS-3372
>                 URL: https://issues.apache.org/jira/browse/MESOS-3372
>             Project: Mesos
>          Issue Type: Improvement
>            Reporter: Chad Heuschober
>
> Some applications workloads would benefit from having access to the statically defined slave attributes. By processing `taskInfo` on the slave such tokens, as defined in `taskInfo` could be replaced with the appropriate values to achieve such objectives as rack locality.
> Example:
> Before token replacement:
> {code}
> {
>   "discovery": {
>     "environment": "RACK_@MESOS.AGENT.ATTRS.RACK_ID@"
>   }
> }
> {code}
> After token replacement:
> {code}
> {
>   "discovery": {
>     "environment": "RACK_DC131R57"
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)