aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zameer Manji <zma...@apache.org>
Subject Re: Build issues: Thermos executor not working
Date Tue, 17 Feb 2015 19:57:51 GMT
I'm picking this up. I have filed
https://issues.apache.org/jira/browse/AURORA-1128 to track my progress in
this issue.

On Tue, Feb 17, 2015 at 9:40 AM, Kevin Sweeney <kevints@apache.org> wrote:

> You'll also need to add the dependency everywhere that depends on
> 3rdparty/python:mesos.interface.
>
> On Tue, Feb 17, 2015 at 9:39 AM, Kevin Sweeney <kevints@apache.org> wrote:
>
> > I ran into this issue as well - it looks like the problem is that Mesos
> > requires protobuf<3, which 3.0.0-alpha1 technically is (pants uses a
> > different resolver than pip - pip will ignore alpha versions unless run
> > with --pre). A workaround is to add an explicit dependency on
> > protobuf==2.6.1 to our 3rdparty/python/requirements.txt and add a
> > dependency on 3rdpary/python:protobuf everywhere that depends on
> > 3rdparty/python:mesos.native.
> >
> > If you fix this, it'd be awesome if you could submit a patch.
> >
> > Thanks,
> > Kevin
> >
> > On Tue, Feb 17, 2015 at 1:06 AM, Erb, Stephan <
> Stephan.Erb@blue-yonder.com
> > > wrote:
> >
> >> Hi everyone,
> >>
> >> we try to build the latest Aurora git version on a Debian 7 host.
> >> Unfortunately, the resulting executor seems to be broken, as it fails to
> >> start with the following message:
> >>
> >>
> >> WARNING: Logging before InitGoogleLogging() is written to STDERR
> >> I0216 18:16:51.178513 25237 fetcher.cpp:76] Fetching URI
> >> '/opt/thermos/bin/thermos_executor.sh'
> >> I0216 18:16:51.178513 25237 fetcher.cpp:179] Copying resource from
> >> '/opt/thermos/bin/thermos_executor.sh' to
> >>
> '/var/lib/mesos/slaves/20141218-095422-1985259712-5050-31688-0/frameworks/20140919-174559-16842879-5050-27194-0000/executors/thermos-1424107010619-stratosphere-staging-strato-stage-service-71-0-9120fb5c-4b4b-425e-90f5-0d83224b9d64/runs/fe198e72-d41e-41c3-a006-27dad0ed758b'
> >> Traceback (most recent call last):
> >>   File "/opt/thermos/bin/thermos_executor.pex/.bootstrap/_pex/pex.py",
> >> line 272, in execute
> >>     self.execute_entry(entry_point, args)
> >>   File "/opt/thermos/bin/thermos_executor.pex/.bootstrap/_pex/pex.py",
> >> line 320, in execute_entry
> >>     runner(entry_point)
> >>   File "/opt/thermos/bin/thermos_executor.pex/.bootstrap/_pex/pex.py",
> >> line 342, in execute_pkg_resources
> >>     runner = entry.load(require=False)  # trust that the environment is
> >> sane
> >>   File
> >> "/opt/thermos/bin/thermos_executor.pex/.bootstrap/pkg_resources.py",
> line
> >> 2048, in load
> >>     entry = __import__(self.module_name, globals(),globals(),
> >> ['__name__'])
> >>   File
> >>
> "/opt/thermos/bin/thermos_executor.pex/apache/aurora/executor/bin/thermos_executor_main.py",
> >> line 24, in <module>
> >>   File
> >>
> "/.pex/install/mesos.native-0.21.1-py2.7-linux-x86_64.egg.b3704775c8aad2e57af36756ac89f16a8ca72ae1/mesos.native-0.21.1-py2.7-linux-x86_64.egg/mesos/native/__init__.py",
> >> line 17, in <module>
> >>     from ._mesos import MesosExecutorDriverImpl
> >>   File
> >>
> "/.pex/install/mesos.interface-0.21.1-py2-none-any.whl.00a9556e7f26cf49f09f1542a1ee274c058ea78c/mesos.interface-0.21.1-py2-none-any.whl/mesos/interface/mesos_pb2.py",
> >> line 4, in <module>
> >>     from google.protobuf.internal import enum_type_wrapper
> >> ImportError: cannot import name enum_type_wrapper
> >>
> >>
> >> I have attached the pants build log. It seems like pants is pulling in a
> >> wrong protobuf version (protobuf-3.0.0_alpha_1 instead of protobuf
> 2.6.1).
> >>
> >> The issue can even be simulated locally:
> >> * pip install mesos.interface with an old virtualenv 1.11 (including pip
> >> 1.5 and setuptools 2.0.2) pulls in protobuf-3.0.0-alpha-1
> >> * pip install mesos.interface with the latest and greatest pip 6.0.8 and
> >> setuptools 12.2 pulls protobuf-2.6.1
> >>
> >> How can this happen? Isn't the "build-support/virtualenv" script
> supposed
> >> to prevent that? I also tried patching the setuptools_version in
> pants.ini,
> >> but it did not help.
> >>
> >> Any ideas?
> >>
> >> Best Regards,
> >> Stephan
> >>
> >>
> >>
> >>
> >>
> >
>



-- 
Zameer Manji

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message