Slow progress from Go front: I am at a point where I am testing this approach using Go.
HTTP Sent: POST /master/mesos.internal.RegisterFrameworkMessage HTTP/1.1 Host: 127.0.0.1:5050 User-Agent: libprocess/scheduler(1)@127.0.0.1:8080 Content-Length: 34 Connection: Keep-Alive Content-Type: application/x-protobuf Accept-Encoding: gzip String representation of protobuf sent: user:"test" name:"gomes" id:<value:"gomes-framework-1" > Master console response W0504 10:53:48.263000 3960 protobuf.hpp:399] Initialization errors: framework.user, framework.name Before I delve in to CPP to see what's going on, hope someone can let me know what I am doing wrong. PS. I havent applied the two patches mentioned here. vladimir.vivien On Wed, Apr 30, 2014 at 1:59 AM, Benjamin Mahler <benjamin.mah...@gmail.com>wrote: > Brian, I'm curious whether most python HTTP libraries support using custom > HTTP request headers. > > We'll land benh's patches to send 202 responses in 0.19.0: > > https://reviews.apache.org/r/20276/ > https://reviews.apache.org/r/20277/ > > Once these get committed, you should be able to get something working > nicely. This will allow libraries like "pesos" to use a custom header > "Libprocess-From" to receive 202 responses for messages. > > We'd also like to get some more foundation laid for the lower-level API, > I'll let benh comment on what else is needed here: > > https://reviews.apache.org/r/20309/ > > > On Sun, Apr 27, 2014 at 9:23 PM, Vetoshkin Nikita < > nikita.vetosh...@gmail.com> wrote: > >> That's great news indeed! >> Maybe there should be a place on mesos site mentioning such efforts? >> >> >> On Mon, Apr 28, 2014 at 5:24 AM, Brian Wickman <wick...@gmail.com> wrote: >> >> > To my knowledge there is no Zookeeper Group implementation for Go yet. >> > There do however appear to be Go zookeeper >> > bindings<https://github.com/samuel/go-zookeeper>. >> > From my day of spelunking through code, it seems that probably the most >> > challenging thing will be getting a ZookeeperMasterDetector >> implementation >> > working correctly to enable Scheduler "high availability" mode for these >> > other languages. >> > >> > Java/Python/C++ have the benefit of preexisting Group implementations >> > (java< >> > >> https://github.com/twitter/commons/blob/master/src/java/com/twitter/common/zookeeper/Group.java >> > > >> > , python< >> > >> https://github.com/twitter/commons/blob/master/src/python/twitter/common/zookeeper/group/kazoo_group.py >> > > >> > , c++< >> > >> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob;f=src/zookeeper/group.cpp;h=70972980dd25618c76eb36e0a31d060c096e36dc;hb=HEAD >> > >) >> > which are the foundation for ZK master detection. An intermediate >> option >> > could be to pull the ZookeeperMasterDetectorProcess out into a >> standalone >> > binary and have the native implementation talk to it as a sort of proxy >> to >> > figure out who the leading master is. But that's not nearly as >> satisfying >> > as a pure language implementation. >> > >> > ~brian >> > >> > >> > On Sun, Apr 27, 2014 at 3:22 PM, Vladimir Vivien >> > <vladimir.viv...@gmail.com>wrote: >> > >> > > It must be the right time for this. I started the same effort for Go. >> > > I am following Kevin's example and Ben's well-documented email (in >> this >> > > thread). >> > > Very early but should have some proof-of-concept working soon. >> > > >> > > https://github.com/vladimirvivien/ionos >> > > >> > > >> > > On Sun, Apr 27, 2014 at 6:07 PM, Tom Arnfeld <t...@duedil.com> wrote: >> > > >> > >> (Sorry to jump into this thread) >> > >> >> > >> I have to say, this is very exciting! It only became apparent to me >> how >> > >> painful it is having to compile the mesos egg into a Python framework >> > the >> > >> past week >> > >> while writing one, especially when running the framework on a >> different >> > >> architecture to the one running the executor! >> > >> >> > >> Looking forward to being able to use this. :-) >> > >> >> > >> It’d be awesome if the API was near identical, so one could switch >> > >> between `mesos` and `pesos` easily… >> > >> >> > >> Tom. >> > >> >> > >> On 27 Apr 2014, at 22:42, Brian Wickman <wick...@gmail.com> wrote: >> > >> >> > >> > And I've started a skeleton implementation of the Mesos framework >> API >> > at >> > >> > https://github.com/wickman/pesos >> > >> > >> > >> > While I vendored the translated protobuf, it would be great to >> tackle >> > >> > https://issues.apache.org/jira/browse/MESOS-857 at some point. >> > >> > >> > >> > >> > >> > On Sun, Apr 27, 2014 at 12:50 PM, Brian Wickman <wick...@gmail.com >> > >> > >> wrote: >> > >> > >> > >> >> I've implemented a pure python version of the basic >> > >> >> Process/ProtobufProcess mechanics and wire protocol. I haven't >> gone >> > >> so far >> > >> >> as Kevin and tried to register a framework or maybe talk to a >> > >> replicated >> > >> >> log, but it shouldn't be much more work: >> > >> >> >> > >> >> https://github.com/wickman/compactor >> > >> >> >> > >> >> Zero documentation but you can read the tests for a general idea >> of >> > >> what's >> > >> >> going on. >> > >> >> >> > >> >> cheers, >> > >> >> brian >> > >> >> >> > >> >> >> > >> >> >> > >> >> On Sun, Apr 13, 2014 at 10:28 PM, Kevin Sweeney < >> > >> kevin.t.swee...@gmail.com >> > >> >>> wrote: >> > >> >> >> > >> >>> I've got the start of a JVM verson on github - it can currently >> > >> register >> > >> >>> a framework and parse the response. Client-side I still need to >> > >> figure out >> > >> >>> how to properly configure Keep-Alive. Servlet can dispatch >> messages >> > to >> > >> >>> message handlers in a type-safe way and returns a 202 for >> messages >> > >> it's >> > >> >>> going to handle. Code's a mess currently. >> > >> >>> >> > >> >>> https://github.com/kevints/mesos-framework-api >> > >> >>> >> > >> >>> >> > >> >>> On Fri, Apr 11, 2014 at 7:12 PM, Benjamin Hindman < >> > >> b...@eecs.berkeley.edu >> > >> >>>> wrote: >> > >> >>> >> > >> >>>> First, my apologies for getting to this party so late. It's >> great >> > to >> > >> see >> > >> >>>> people interested in helping create native-language Mesos >> > libraries. >> > >> >>>> >> > >> >>>> Vladimir: my presentation was definitely referring to the the >> > >> low-level >> > >> >>>> protocol between master, framework (scheduler), slave, and >> > >> executors. I'll >> > >> >>>> do my best here to clarify how the current protocol works and >> what >> > >> we need >> > >> >>>> to do to get it to the point where we can write native-language >> > >> libraries. >> > >> >>>> (Eventually it would be great to move some of this into >> > >> documentation as >> > >> >>>> necessary.) >> > >> >>>> >> > >> >>>> As Nikita pointed out, the protocol is currently "HTTP-like". >> As my >> > >> >>>> presentation describes, think actors and one-way message passing >> > when >> > >> >>>> considering how the protocol works. >> > >> >>>> >> > >> >>>> To send a message an actor POSTs an HTTP request where the actor >> > >> that is >> > >> >>>> supposed to receive the message is the first component of the >> > >> request path >> > >> >>>> and the name of the message is the remaining part of the path. >> To >> > >> >>>> distinguish one of these "messages" from a normal HTTP request >> we >> > >> look to >> > >> >>>> see if the 'User-Agent' is 'libprocess/...'. For example: >> > >> >>>> >> > >> >>>> POST /master/mesos.internal.RegisterFrameworkMessage HTTP/1.1 >> > >> >>>> User-Agent: libprocess/scheduler(1)@10.0.1.7:53523 >> > >> >>>> >> > >> >>>> ... represents a message with the name >> > >> >>>> 'mesos.internal.RegisterFrameworkMessage' destined for the actor >> > >> 'master' >> > >> >>>> coming from the actor 'scheduler(1)' at 10.0.1.7:53523. If the >> > >> 'master' >> > >> >>>> actor were to send a message back it would look something like >> > this: >> > >> >>>> >> > >> >>>> POST /scheduler(1)/mesos.internal.FrameworkRegisteredMessage >> > HTTP/1.1 >> > >> >>>> User-Agent: libprocess/master@10.0.1.7:5050 >> > >> >>>> >> > >> >>>> So, one-way message passing via HTTP POST. >> > >> >>>> >> > >> >>>> The message data is captured as the body of the HTTP request >> (which >> > >> can >> > >> >>>> be specified using _either_ Content-Length or a >> Transfer-Encoding, >> > >> and as >> > >> >>>> Nikita points out we use chunked transfer encoding internally). >> The >> > >> data is >> > >> >>>> arbitrary and the actor ultimately decides how it wants to >> "parse" >> > >> it. In >> > >> >>>> Mesos, 99% of our messages use serialized protobufs, but we also >> > >> send a few >> > >> >>>> messages with just arbitrary data. All this really means is that >> > >> knowing >> > >> >>>> the actor and message name is not enough, you also need to know >> > what >> > >> the >> > >> >>>> body type is supposed to be for that message. In the future >> we'll >> > >> probably >> > >> >>>> enable messages with either JSON or serialized protobuf[1] ... >> for >> > >> now, >> > >> >>>> just serialized protobuf. >> > >> >>>> >> > >> >>>> Okay, so where does this break down when trying to do this >> > >> >>>> language-natively? I've had some of this in the works and this >> > >> conversation >> > >> >>>> has motivated me to publish some reviews addressing the issues: >> > >> >>>> >> > >> >>>> (1) We'll need to return a response if one plans to use a native >> > HTTP >> > >> >>>> library since it'll expect request/response. >> > >> >>>> https://reviews.apache.org/r/20276 introduces responding with a >> > '202 >> > >> >>>> Accepted' for these messages (from the HTTP specification, a >> '202 >> > >> >>>> Accepted': "The request has been accepted for processing, but >> the >> > >> >>>> processing has not been completed. The request might or might >> not >> > >> >>>> eventually be acted upon, as it might be disallowed when >> processing >> > >> >>>> actually takes place. There is no facility for re-sending a >> status >> > >> code >> > >> >>>> from an asynchronous operation such as this."). >> > >> >>>> >> > >> >>>> (2) Most HTTP libraries will set their 'User-Agent' themselves, >> so >> > >> >>>> https://reviews.apache.org/r/20277 introduces a >> 'libprocess-from' >> > >> >>>> header that works similar to User-Agent. There is still some >> > cleanup >> > >> I'd >> > >> >>>> love to do around stringification of PIDs (the underlying type >> > Mesos >> > >> uses >> > >> >>>> for remote actors, inspired by Erlang). Until then, the >> > >> 'libprocess-from' >> > >> >>>> string is unfortunately esoteric (see the test). >> > >> >>>> >> > >> >>>> The combination of these two patches should make sending and >> > >> receiving >> > >> >>>> messages straightforward. However, we still plan to expose the >> > >> low-level >> > >> >>>> Event and Call protobuf messages and that will be the preferred >> > >> approach >> > >> >>>> for building a native-language library. Follow along at >> > >> >>>> https://issues.apache.org/jira/browse/MESOS-1127 for more >> details. >> > >> (To >> > >> >>>> be clear, you'd still be able to implement native-language >> > libraries >> > >> with >> > >> >>>> the patches above but we'll be deprecating the protobufs you'd >> be >> > >> using in >> > >> >>>> favor of Event and Call protobufs instead. If you're eager to >> get >> > >> that >> > >> >>>> going before Event and Call are committed I'm happy to discuss >> the >> > >> existing >> > >> >>>> protobufs in more detail.) >> > >> >>>> >> > >> >>>> I hope this helps. >> > >> >>>> >> > >> >>>> Ben. >> > >> >>>> >> > >> >>>> >> > >> >>>> On Fri, Apr 11, 2014 at 4:54 AM, Vladimir Vivien < >> > >> >>>> vladimir.viv...@gmail.com> wrote: >> > >> >>>> >> > >> >>>>> Nikita >> > >> >>>>> Thanks for the JIRA. >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> On Wed, Apr 9, 2014 at 2:16 PM, Vetoshkin Nikita < >> > >> >>>>> nikita.vetosh...@gmail.com >> > >> >>>>>> wrote: >> > >> >>>>> >> > >> >>>>>> 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=n5GT7OFSh58fromBen >> > >> >>>>>>> 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 >> > >> >>>>>>>> >> > >> >>>>>>> >> > >> >>>>>> >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> -- >> > >> >>>>> Vladimir Vivien >> > >> >>>>> >> > >> >>>> >> > >> >>>> >> > >> >>> >> > >> >> >> > >> >> > >> >> > > >> > > >> > > -- >> > > Vladimir Vivien >> > > >> > >> > > -- Vladimir Vivien
