Benjamin Mahler created MESOS-3012:
--------------------------------------
Summary: Support existing message passing optimization with
Event/Call.
Key: MESOS-3012
URL: https://issues.apache.org/jira/browse/MESOS-3012
Project: Mesos
Issue Type: Task
Reporter: Benjamin Mahler
See the thread here:
http://markmail.org/thread/wvapc7vkbv7z6gbx
The scheduler driver currently sends framework messages directly to the slave,
when possible:
{noformat}
(through master)
Scheduler —————> Master —————> Slave ————> Executor
Driver ————————————————————> Driver
(skip master)
{noformat}
The slave always sends messages directly to the scheduler driver:
{noformat}
Scheduler Master Slave <———— Executor
Driver <———————————————————— Driver
(skip master)
{noformat}
In order for the scheduler driver to receive Events from the master, it needs
enough information to continue directly sending messages to slaves. This was
previously accomplished by sending the slave's pid inside the [offer
message|https://github.com/apache/mesos/blob/0.23.0-rc1/src/messages/messages.proto#L168]:
{code}
message ResourceOffersMessage {
repeated Offer offers = 1;
repeated string pids = 2;
}
{code}
We could add an 'Address' to the Offer protobuf to provide the scheduler driver
with the same information:
{code}
message Address {
required string ip;
required string hostname;
required uint32_t port;
// All HTTP requests to this address must begin with this prefix.
required string path_prefix;
}
message Offer {
required OfferID id = 1;
required FrameworkID framework_id = 2;
required SlaveID slave_id = 3;
required string hostname = 4; // Deprecated in favor of 'address'.
optional Address address = 8; // Obviates 'hostname'.
...
}
{code}
The path prefix is required for testing purposes, where we can have multiple
slaves within a process (e.g. {{localhost:5051/slave(1)/state.json}} vs.
{{localhost:5051/slave(2)/state.json}}).
This provides enough information to allow the scheduler driver to continue to
directly send messages to the slaves, which unblocks MESOS-2910.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
