BTW, there is also somehow related ticket https://issues.apache.org/jira/browse/MESOS-930
On Wed, Apr 9, 2014 at 9:54 PM, Benjamin Mahler <benjamin.mah...@gmail.com>wrote: > > > > I thought the low-level api being referred in the > > video had to do with communication between master and framework|executor > > for scheduling. But, it's really administrative. I thought that would > > have been an opportunity for a Go binding that did not require the C++ > > libraries. > > > > Vladimir, the low-level API referred to in the talk is exactly what you're > interpreting, it is for communication between master and scheduler, and > slave and executor. You could definitely build pure go bindings as you > described, just not with JSON. > > Forget I mentioned anything about the administrative endpoints and JSON, as > I see that's leading to confusion. ;) > > On Wed, Apr 9, 2014 at 3:39 AM, Vladimir Vivien > <vladimir.viv...@gmail.com>wrote: > > > Ben, > > Thank you for clarifying. I thought the low-level api being referred in > the > > video had to do with communication between master and framework|executor > > for scheduling. But, it's really administrative. I thought that would > > have been an opportunity for a Go binding that did not require the C++ > > libraries. > > > > Thanks anyway. > > > > > > > > > > > > > > On Tue, Apr 8, 2014 at 4:52 PM, Benjamin Mahler > > <benjamin.mah...@gmail.com>wrote: > > > > > Sorry, I was not referring to implementing a scheduler via JSON instead > > of > > > protobuf, in theory that would be possible but there has been no > planning > > > in this area. Sorry for the confusion. > > > > > > I was referring to administrative endpoints. For example, kicking a > > > framework out or telling the master a slave is needs to be repaired. > > These > > > endpoints may rely on the ability to convert JSON to internal > protobufs. > > > > > > Can you clarify what you're looking to do? Are you looking to implement > > an > > > API in Go that communicates with JSON instead of serialized protobuf? > > > > > > On Tue, Apr 8, 2014 at 1:19 PM, Vladimir Vivien > > > <vladimir.viv...@gmail.com>wrote: > > > > > > > Ben, > > > > That is exactly what I am asking. > > > > Is that something coming up soon, is there a JIRA I can look at? > > > > I wanna get early start on a native json Go api or even help out if > > > > possible. > > > > > > > > > > > > On Tue, Apr 8, 2014 at 3:25 PM, Benjamin Mahler > > > > <benjamin.mah...@gmail.com>wrote: > > > > > > > > > +vinod, benh > > > > > > > > > > Hey Vladimir, there will be some authenticated REST endpoints at > some > > > > > point, there is some work in this area underway. > > > > > > > > > > We have the ability to encode protobuf messages as JSON, so the > plan > > > was > > > > to > > > > > have any REST endpoints directly use JSON to send us protobuf > > messages. > > > > I'm > > > > > not sure if this is what you're asking though? > > > > > > > > > > > > > > > On Tue, Apr 8, 2014 at 11:13 AM, Vetoshkin Nikita < > > > > > nikita.vetosh...@gmail.com> wrote: > > > > > > > > > > > I'm not a mesos guy, just very curious. But in my opinion - I > doubt > > > it, > > > > > > HTTP is synchronous request-response protocol. Mesos needs > > something > > > > more > > > > > > robust for message passing. Websockets anyone? :) > > > > > > > > > > > > > > > > > > On Tue, Apr 8, 2014 at 10:08 PM, Vladimir Vivien > > > > > > <vladimir.viv...@gmail.com>wrote: > > > > > > > > > > > > > Ben / Nikita > > > > > > > Thanks for the pointers. > > > > > > > So, (without digging yet) is it a fair summary to say that > > > libprocess > > > > > > wraps > > > > > > > protobufs-encoded calls and push them over HTTP to > master/slaves > > ? > > > > Will > > > > > > > protobuf (eventually) be supplanted by direct HTTP via REST or > > > > similar > > > > > ? > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 7, 2014 at 2:54 PM, Vetoshkin Nikita < > > > > > > > nikita.vetosh...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > > > > > Or, just to get to know - you can take tcpdump and take a > look > > :) > > > > > > > > > > > > > > > > I personally wouldn't call that HTTP. Something "HTTP-like" > > would > > > > > > > describe > > > > > > > > it better. Because it's not request-response. It's just > message > > > > > > passing, > > > > > > > no > > > > > > > > need to wait for the answer - send new message one after > > another. > > > > > Every > > > > > > > > message is POST with address and message type encoded in URI: > > > POST > > > > > > > > /executor(1)/mesos.internal.RunTaskMessage. Sender is encoded > > in > > > > > > > User-Agent > > > > > > > > header, e.g: libprocess/slave(1)@127.0.0.1:5051. Body > contains > > > > > > protobuf > > > > > > > > message, Transfer-Encoding is always "chunked". > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 7, 2014 at 10:42 PM, Benjamin Mahler > > > > > > > > <benjamin.mah...@gmail.com>wrote: > > > > > > > > > > > > > > > > > Unfortunately you will need to learn this by looking at the > > > code > > > > in > > > > > > > > > libprocess, as the message passing format is not explicitly > > > > > > documented > > > > > > > at > > > > > > > > > the current time. > > > > > > > > > > > > > > > > > > Start with calls like ProtobufProcess::send() and dig your > > way > > > > > down. > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Apr 5, 2014 at 7:52 AM, Vladimir Vivien > > > > > > > > > <vladimir.viv...@gmail.com>wrote: > > > > > > > > > > > > > > > > > > > I was watching this video from > > > > > > > > > > https://www.youtube.com/watch?v=n5GT7OFSh58from Ben > where > > he > > > > > > talked > > > > > > > > > > about the wire protocol for Mesos being done in > > > > > > > > > > HTTP. > > > > > > > > > > > > > > > > > > > > Where can I learn about the low-level wire protocol > either > > in > > > > > > > > > documentation > > > > > > > > > > or browsing through the code. > > > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Vladimir Vivien > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Vladimir Vivien > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Vladimir Vivien > > > > > > > > > > > > > > > -- > > Vladimir Vivien > > >
