On Tuesday, June 7, 2016, Du, Fan <fan...@intel.com> wrote: > > > On 2016/6/6 23:48, Jörg Schad wrote: > >> Hi, >> thanks for your idea and design doc! >> Just a few thoughts: >> a) The scheduling part would be implemented in a framework scheduler and >> not the Mesos Core, or? >> > > I'm not sure which level of scheduling part do you indicate, > For the "Future" section of proposal?, It's Mesos allocation logic. > And how to use rack information to implement advanced features (fault > tolerance, > data locality) is up to the framework scheduling part. > > b) As mentioned by James, this needs to be very flexible (and not >> necessarily based on network structure), >> > > The proposed network topology detection is modular, to fit into Ethernet, > Infiniband, or other network implementation. And yes, user can statically > configure /etc/mesos/rack_id to manipulate the logical network topology > easily. > > > afaik people are using labels >> on the agents to identify different fault domains which can then be >> interpreted by framework scheduler. Maybe it would make sense (instead >> of identifying the network structure) to come up with a common label >> naming scheme which can be understood by all/different frameworks. >> > > I'm not convinced here why still using labels, > Based on what information to label the agents? IMO, cluster operator > still needs something like lldp to find out the network topology, > every cluster operator will need to do it by his own, and it's better > to abstract the logical inside Mesos to provide common interface to > frameworks.
LLDP is Ethernet specific however. To go into Mesos, it would need to be higher level as there are people who run Mesos with Infiniband or perhaps an exotic custom networking fabric (Cray and IBM bits come to mind) that might want to take advantage of this functionality. Labels are more generic, but also more flexible in that regard. -- Text by Jeff, typos by iPhone
