[
https://issues.apache.org/jira/browse/MESOS-3366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14735888#comment-14735888
]
Felix Abecassis commented on MESOS-3366:
----------------------------------------
{quote}
Prefer to script; because lots of developer/operators are NOT good at C++,
it'll be hard for them to build a strong C++ module to detect
resources/attributes; and the only interaction with Mesos is its output which
can be handled well by script.
{quote}
I understand your point, but for better or for worse, Mesos is written in C++
so it seems more sensible to start from there and improve afterwards. If I
understand what [~cdoyle] suggested above, we could add a module that will
execute any script, I think that's a good idea and it will fit your use case.
{quote}
Module have the similar concern: will provide several interfaces. But we can
design the output format to cover them, for example,
ip:ip_discovery_command.sh, resources:resources_script.sh, topology:
topology_script.sh
{quote}
>From what I understand, a shared library can implement multiple modules. So,
>for a specific accelerator, we could have a single library implementing the
>resource hook, the attribute hook, and eventually the topology hook for this
>accelerator. This could be beneficial for code reuse inside the shared library.
{quote}
For the compatibility, it depends on our design.
{quote}
I'm curious, how would you design your solution to handle version compatibility?
{quote}
Not sure the case.
{quote}
I'm sorry, I didn't get that.
{quote}
Both module & script need to build a wrapper to merge the output; but script is
easier to develop, e.g. it's easy for Python to parse the output of each script
and merge them together.
{quote}
With the module approach, I think we could simply chain the different callbacks
after calling the default resource discovery code (for cpu/mem/disk). The order
of calls could simply be the order in which modules were defined. So, with this
approach you don't need to build a wrapper, it's handled by the Mesos core. The
first hook might decide to remove one cpu from the resource set, and the
subsequent hooks will see this modification without knowing what happened
before them. With multiple independent wrapper scripts, you will need a
strategy for merging if a script says {{cpus:5}} and another script reports
{{cpus:4}}.
> Allow resources/attributes discovery
> ------------------------------------
>
> Key: MESOS-3366
> URL: https://issues.apache.org/jira/browse/MESOS-3366
> Project: Mesos
> Issue Type: Improvement
> Components: slave
> Reporter: Felix Abecassis
>
> In heterogeneous clusters, tasks sometimes have strong constraints on the
> type of hardware they need to execute on. The current solution is to use
> custom resources and attributes on the agents. Detecting non-standard
> resources/attributes requires wrapping the "mesos-slave" binary behind a
> script and use custom code to probe the agent. Unfortunately, this approach
> doesn't allow composition. The solution would be to provide a hook/module
> mechanism to allow users to use custom code performing resources/attributes
> discovery.
> Please review the detailed document below:
> https://docs.google.com/document/d/15OkebDezFxzeyLsyQoU0upB0eoVECAlzEkeg0HQAX9w
> Feel free to express comments/concerns by annotating the document or by
> replying to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
