You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Tom Arnfeld <to...@duedil.com> on 2014/07/21 21:45:41 UTC
Mesos/Libprocess API
Hey,
I've started to try and finish off the work @wickman started around pesos[1] and compactor[2] - pure language bindings for mesos and libprocess in Python. It's currently far from finished, but have fun into a brick wall around libprocess. If anyone could shed any light that'd be great.
To start with, I saw the framework register but disconnect immediately. From a quick chat on IRC someone mentioned this could be related to not keeping the inbound message connection open, the one that sends mesos.internal.FrameworkRegisteredMessage. In doing this, the framework does register with the master and shows up in the UI – however no further messages are received at all. I'm keeping the outbound connection open already.
Mesos seems to think it's sending offers (they show up in the logs and are showing in the Offers page) but the master never gets past there, and the framework never receives the HTTP connections. No doubt this is a bug in the socket logic on my end. Struggling to find my way through the libprocess source to figure it out.
Any pointers would be much appreciated.
Thanks!
Tom.
[1] https://github.com/wickman/pesos
[2] https://github.com/wickman/compactor
Re: Mesos/Libprocess API
Posted by Tom Arnfeld <to...@duedil.com>.
Hey!
Thanks for the reply. After a painful few days I managed to narrow it down to an error (that was being swallowed, grr!!) as a result of an implementation bug in Tornado (the python library we're using for the libprocess http service). I've since submitted a patch here https://github.com/tornadoweb/tornado/pull/1124 - feel free to chime in!
This highlights an issue with Mesos which I have also opened here https://issues.apache.org/jira/browse/MESOS-1625. I'd love to get any input on the problem, as i'm a little scared about the consequences if this were to be fixed.
In other news, pesos is now working and i'm finishing off the rest of the actions/callback implementations today.
Tom.
On 23 Jul 2014, at 07:42, Vetoshkin Nikita <ni...@gmail.com> wrote:
> Hi, Tom!
> I would gladly help you to debug if you could provide some information
> about your setup. Is it localhost only communication? Any code snippet to
> reproduce the problem?
>
> P.S. I'm trying to setup pesos and it seems like python3.3 is a requirement
> but it isn't mentioned anywhere.
>
>
> On Tue, Jul 22, 2014 at 1:45 AM, Tom Arnfeld <to...@duedil.com> wrote:
>
>> Hey,
>>
>> I've started to try and finish off the work @wickman started around
>> pesos[1] and compactor[2] - pure language bindings for mesos and libprocess
>> in Python. It's currently far from finished, but have fun into a brick wall
>> around libprocess. If anyone could shed any light that'd be great.
>>
>> To start with, I saw the framework register but disconnect immediately.
>> From a quick chat on IRC someone mentioned this could be related to not
>> keeping the inbound message connection open, the one that sends
>> mesos.internal.FrameworkRegisteredMessage. In doing this, the framework
>> does register with the master and shows up in the UI – however no further
>> messages are received at all. I'm keeping the outbound connection open
>> already.
>>
>> Mesos seems to think it's sending offers (they show up in the logs and are
>> showing in the Offers page) but the master never gets past there, and the
>> framework never receives the HTTP connections. No doubt this is a bug in
>> the socket logic on my end. Struggling to find my way through the
>> libprocess source to figure it out.
>>
>> Any pointers would be much appreciated.
>>
>> Thanks!
>>
>> Tom.
>>
>> [1] https://github.com/wickman/pesos
>> [2] https://github.com/wickman/compactor
Re: Mesos/Libprocess API
Posted by Tom Arnfeld <to...@duedil.com>.
Fair enough. I've updated my two forks with an extra option in the
setup.cfg file that uses a different build directory to solve that problem.
I have no issue with using pants or or not (so long as vanilla setuptools
works), though I was having issues getting pants to use these forks (via
the git support built into setuptools) in an external project, so gave up
and just used pip.
On 23 July 2014 17:42, Brian Wickman <wi...@apache.org> wrote:
> They can be installed via setuptools -- the repositories have setup.py
> files included at the root so that source distributions can be made.
> Nothing's been published to pypi yet though, since I don't feel they're
> even ready for an 0.1 release. I pantsified the repositories to make it
> easier to run tests, but am happy to toxify them instead -- whatever people
> are most comfortable with. Re: BUILD vs build, you should be able to
> specify an alternate build path for setuptools so that it doesn't conflict
> when building distributions.
>
>
> On Wed, Jul 23, 2014 at 12:01 AM, Tom Arnfeld <to...@duedil.com> wrote:
>
> > R.E Python 3.3;
> >
> > It doesn't actually require it, but it's importing asyncio directly
> > instead of using the standard try/catch around the import and falling
> back
> > to trollius (the Python2 port). We can probably import via tornado, which
> > does this try/catch for us.
> >
> > Right now both compactor and pesos can't be installed with setuptools due
> > to the BUILD files (setuptools tries to create build folders and the name
> > conflicts). I'll be fixing this up today by removing pants, at least just
> > to get it working... not sure how Brian feels about that yet ;-)
> >
> > I can ping the mailing list once both compactor and pesos are up and
> > running in an easy-to-use way (next few hours). I've been using
> > https://github.com/tarnfeld/mesos-python-framework as a test framework
> > skeleton, but that's also not easy to set up just yet.
> >
> > Note: Regardless of the above, you need to have installed our fork of
> > tornado for anything to work beyond the first round of messages.
> >
> > Cheers,
> >
> > Tom.
> >
> > On 23 Jul 2014, at 07:42, Vetoshkin Nikita <ni...@gmail.com>
> > wrote:
> >
> > > Hi, Tom!
> > > I would gladly help you to debug if you could provide some information
> > > about your setup. Is it localhost only communication? Any code snippet
> to
> > > reproduce the problem?
> > >
> > > P.S. I'm trying to setup pesos and it seems like python3.3 is a
> > requirement
> > > but it isn't mentioned anywhere.
> > >
> > >
> > > On Tue, Jul 22, 2014 at 1:45 AM, Tom Arnfeld <to...@duedil.com> wrote:
> > >
> > >> Hey,
> > >>
> > >> I've started to try and finish off the work @wickman started around
> > >> pesos[1] and compactor[2] - pure language bindings for mesos and
> > libprocess
> > >> in Python. It's currently far from finished, but have fun into a brick
> > wall
> > >> around libprocess. If anyone could shed any light that'd be great.
> > >>
> > >> To start with, I saw the framework register but disconnect
> immediately.
> > >> From a quick chat on IRC someone mentioned this could be related to
> not
> > >> keeping the inbound message connection open, the one that sends
> > >> mesos.internal.FrameworkRegisteredMessage. In doing this, the
> framework
> > >> does register with the master and shows up in the UI – however no
> > further
> > >> messages are received at all. I'm keeping the outbound connection open
> > >> already.
> > >>
> > >> Mesos seems to think it's sending offers (they show up in the logs and
> > are
> > >> showing in the Offers page) but the master never gets past there, and
> > the
> > >> framework never receives the HTTP connections. No doubt this is a bug
> in
> > >> the socket logic on my end. Struggling to find my way through the
> > >> libprocess source to figure it out.
> > >>
> > >> Any pointers would be much appreciated.
> > >>
> > >> Thanks!
> > >>
> > >> Tom.
> > >>
> > >> [1] https://github.com/wickman/pesos
> > >> [2] https://github.com/wickman/compactor
> >
> >
>
Re: Mesos/Libprocess API
Posted by Brian Wickman <wi...@apache.org>.
They can be installed via setuptools -- the repositories have setup.py
files included at the root so that source distributions can be made.
Nothing's been published to pypi yet though, since I don't feel they're
even ready for an 0.1 release. I pantsified the repositories to make it
easier to run tests, but am happy to toxify them instead -- whatever people
are most comfortable with. Re: BUILD vs build, you should be able to
specify an alternate build path for setuptools so that it doesn't conflict
when building distributions.
On Wed, Jul 23, 2014 at 12:01 AM, Tom Arnfeld <to...@duedil.com> wrote:
> R.E Python 3.3;
>
> It doesn't actually require it, but it's importing asyncio directly
> instead of using the standard try/catch around the import and falling back
> to trollius (the Python2 port). We can probably import via tornado, which
> does this try/catch for us.
>
> Right now both compactor and pesos can't be installed with setuptools due
> to the BUILD files (setuptools tries to create build folders and the name
> conflicts). I'll be fixing this up today by removing pants, at least just
> to get it working... not sure how Brian feels about that yet ;-)
>
> I can ping the mailing list once both compactor and pesos are up and
> running in an easy-to-use way (next few hours). I've been using
> https://github.com/tarnfeld/mesos-python-framework as a test framework
> skeleton, but that's also not easy to set up just yet.
>
> Note: Regardless of the above, you need to have installed our fork of
> tornado for anything to work beyond the first round of messages.
>
> Cheers,
>
> Tom.
>
> On 23 Jul 2014, at 07:42, Vetoshkin Nikita <ni...@gmail.com>
> wrote:
>
> > Hi, Tom!
> > I would gladly help you to debug if you could provide some information
> > about your setup. Is it localhost only communication? Any code snippet to
> > reproduce the problem?
> >
> > P.S. I'm trying to setup pesos and it seems like python3.3 is a
> requirement
> > but it isn't mentioned anywhere.
> >
> >
> > On Tue, Jul 22, 2014 at 1:45 AM, Tom Arnfeld <to...@duedil.com> wrote:
> >
> >> Hey,
> >>
> >> I've started to try and finish off the work @wickman started around
> >> pesos[1] and compactor[2] - pure language bindings for mesos and
> libprocess
> >> in Python. It's currently far from finished, but have fun into a brick
> wall
> >> around libprocess. If anyone could shed any light that'd be great.
> >>
> >> To start with, I saw the framework register but disconnect immediately.
> >> From a quick chat on IRC someone mentioned this could be related to not
> >> keeping the inbound message connection open, the one that sends
> >> mesos.internal.FrameworkRegisteredMessage. In doing this, the framework
> >> does register with the master and shows up in the UI – however no
> further
> >> messages are received at all. I'm keeping the outbound connection open
> >> already.
> >>
> >> Mesos seems to think it's sending offers (they show up in the logs and
> are
> >> showing in the Offers page) but the master never gets past there, and
> the
> >> framework never receives the HTTP connections. No doubt this is a bug in
> >> the socket logic on my end. Struggling to find my way through the
> >> libprocess source to figure it out.
> >>
> >> Any pointers would be much appreciated.
> >>
> >> Thanks!
> >>
> >> Tom.
> >>
> >> [1] https://github.com/wickman/pesos
> >> [2] https://github.com/wickman/compactor
>
>
Re: Mesos/Libprocess API
Posted by Tom Arnfeld <to...@duedil.com>.
R.E Python 3.3;
It doesn't actually require it, but it's importing asyncio directly instead of using the standard try/catch around the import and falling back to trollius (the Python2 port). We can probably import via tornado, which does this try/catch for us.
Right now both compactor and pesos can't be installed with setuptools due to the BUILD files (setuptools tries to create build folders and the name conflicts). I'll be fixing this up today by removing pants, at least just to get it working... not sure how Brian feels about that yet ;-)
I can ping the mailing list once both compactor and pesos are up and running in an easy-to-use way (next few hours). I've been using https://github.com/tarnfeld/mesos-python-framework as a test framework skeleton, but that's also not easy to set up just yet.
Note: Regardless of the above, you need to have installed our fork of tornado for anything to work beyond the first round of messages.
Cheers,
Tom.
On 23 Jul 2014, at 07:42, Vetoshkin Nikita <ni...@gmail.com> wrote:
> Hi, Tom!
> I would gladly help you to debug if you could provide some information
> about your setup. Is it localhost only communication? Any code snippet to
> reproduce the problem?
>
> P.S. I'm trying to setup pesos and it seems like python3.3 is a requirement
> but it isn't mentioned anywhere.
>
>
> On Tue, Jul 22, 2014 at 1:45 AM, Tom Arnfeld <to...@duedil.com> wrote:
>
>> Hey,
>>
>> I've started to try and finish off the work @wickman started around
>> pesos[1] and compactor[2] - pure language bindings for mesos and libprocess
>> in Python. It's currently far from finished, but have fun into a brick wall
>> around libprocess. If anyone could shed any light that'd be great.
>>
>> To start with, I saw the framework register but disconnect immediately.
>> From a quick chat on IRC someone mentioned this could be related to not
>> keeping the inbound message connection open, the one that sends
>> mesos.internal.FrameworkRegisteredMessage. In doing this, the framework
>> does register with the master and shows up in the UI – however no further
>> messages are received at all. I'm keeping the outbound connection open
>> already.
>>
>> Mesos seems to think it's sending offers (they show up in the logs and are
>> showing in the Offers page) but the master never gets past there, and the
>> framework never receives the HTTP connections. No doubt this is a bug in
>> the socket logic on my end. Struggling to find my way through the
>> libprocess source to figure it out.
>>
>> Any pointers would be much appreciated.
>>
>> Thanks!
>>
>> Tom.
>>
>> [1] https://github.com/wickman/pesos
>> [2] https://github.com/wickman/compactor
Re: Mesos/Libprocess API
Posted by Vetoshkin Nikita <ni...@gmail.com>.
Hi, Tom!
I would gladly help you to debug if you could provide some information
about your setup. Is it localhost only communication? Any code snippet to
reproduce the problem?
P.S. I'm trying to setup pesos and it seems like python3.3 is a requirement
but it isn't mentioned anywhere.
On Tue, Jul 22, 2014 at 1:45 AM, Tom Arnfeld <to...@duedil.com> wrote:
> Hey,
>
> I've started to try and finish off the work @wickman started around
> pesos[1] and compactor[2] - pure language bindings for mesos and libprocess
> in Python. It's currently far from finished, but have fun into a brick wall
> around libprocess. If anyone could shed any light that'd be great.
>
> To start with, I saw the framework register but disconnect immediately.
> From a quick chat on IRC someone mentioned this could be related to not
> keeping the inbound message connection open, the one that sends
> mesos.internal.FrameworkRegisteredMessage. In doing this, the framework
> does register with the master and shows up in the UI – however no further
> messages are received at all. I'm keeping the outbound connection open
> already.
>
> Mesos seems to think it's sending offers (they show up in the logs and are
> showing in the Offers page) but the master never gets past there, and the
> framework never receives the HTTP connections. No doubt this is a bug in
> the socket logic on my end. Struggling to find my way through the
> libprocess source to figure it out.
>
> Any pointers would be much appreciated.
>
> Thanks!
>
> Tom.
>
> [1] https://github.com/wickman/pesos
> [2] https://github.com/wickman/compactor