Project: mesos
Issue MESOS-3012: Support existing message passing optimization with Event/Call.
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.
Story points: 1