Re: Need a shepherd for MESOS--3317

2016-01-26 Thread Abhishek Dasgupta 

Hi Vinod,

Can you review the patch https://reviews.apache.org/r/42794/ ? Or, if 
you can delegate someone else to review the patch. This is my first 
review request in mesos. Thank you.


On Thursday 21 January 2016 03:11 PM, Abhishek Dasgupta wrote:

Hi,

Can anybody please shepherd for 
https://issues.apache.org/jira/browse/MESOS-3317 ?




--
  Regards,

  
---
  Abhishek Dasgupta
  Linux Software Developer - Linux Technology Centre
  IBM Systems Lab,
  IBM India Pvt. Ltd.
  Embassy Golf Link, D Block
  Koramongala - Off Indiranagar Ring Road
  Bangalore - 560 071
  Mobile: +91-8884107981
  
---

[VOTE] Release Apache Mesos 0.27.0 (rc1)

2016-01-26 Thread Timothy Chen 
Hi all,

Please vote on releasing the following candidate as Apache Mesos 0.27.0.

0.27.0 includes the following:

We added major features such as Implicit Roles, Quota, Multiple Disks and more.

We also added major bug fixes such as performance improvements to
state.json requests and GLOG.

The CHANGELOG for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.0-rc1


The candidate for Mesos 0.27.0 release is available at:
https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz

The tag to be voted on is 0.27.0-rc1:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.27.0-rc1

The MD5 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz.md5

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz.asc

The PGP key used to sign the release is here:
https://dist.apache.org/repos/dist/release/mesos/KEYS

The JAR is up in Maven in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1097

Please vote on releasing this package as Apache Mesos 0.27.0!

The vote is open until Fri Jan 29 23:59:59 PST 2016 and passes if a
majority of at least 3 +1 PMC votes are cast.

[ ] +1 Release this package as Apache Mesos 0.27.0
[ ] -1 Do not release this package because ...

Thanks,

Tim, MPark and Kapil

Re: Need a shepherd for MESOS--3317

2016-01-26 Thread Abhishek Dasgupta 

Hi Kapil,

Added you to the reviewer list. Kindly let me know if anything more is 
required from my side.


On Wednesday 27 January 2016 11:17 AM, Kapil Arya wrote:

Hi Abhishek,

I can shepherd this for you. Please add me to the RR.

Kapil

On Wed, Jan 27, 2016 at 12:31 AM, Abhishek Dasgupta
 wrote:

Vinod, Can you point me someone whom I can ask for the review?


On Wednesday 27 January 2016 12:07 AM, Vinod Kone wrote:

Sorry Abhishek, I don't have cycles :(

On Tue, Jan 26, 2016 at 3:18 AM, Abhishek Dasgupta <
a10gu...@linux.vnet.ibm.com> wrote:


Hi Vinod,

Can you review the patch https://reviews.apache.org/r/42794/ ? Or, if you
can delegate someone else to review the patch. This is my first review
request in mesos. Thank you.


On Thursday 21 January 2016 03:11 PM, Abhishek Dasgupta wrote:


Hi,

Can anybody please shepherd for
https://issues.apache.org/jira/browse/MESOS-3317 ?



--
Regards,



---
Abhishek Dasgupta
Linux Software Developer - Linux Technology Centre
IBM Systems Lab,
IBM India Pvt. Ltd.
Embassy Golf Link, D Block
Koramongala - Off Indiranagar Ring Road
Bangalore - 560 071
Mobile: +91-8884107981


---



--
   Regards,


---
   Abhishek Dasgupta
   Linux Software Developer - Linux Technology Centre
   IBM Systems Lab,
   IBM India Pvt. Ltd.
   Embassy Golf Link, D Block
   Koramongala - Off Indiranagar Ring Road
   Bangalore - 560 071
   Mobile: +91-8884107981

---



--
  Regards,

  
---
  Abhishek Dasgupta
  Linux Software Developer - Linux Technology Centre
  IBM Systems Lab,
  IBM India Pvt. Ltd.
  Embassy Golf Link, D Block
  Koramongala - Off Indiranagar Ring Road
  Bangalore - 560 071
  Mobile: +91-8884107981
  
---

Re: Install some 3rdparty packages needed for building Mesos modules

2016-01-26 Thread James Peach 

> On Jan 26, 2016, at 10:54 AM, Kapil Arya  wrote:
> 
> Thanks for the feedback, Alex! I have inlined my responses.
> 
>> First, I think we should support two use cases: installing 3rdparty
>> packages and exposing them in the local build. As a Mesos (module)
>> developer, I may have different versions of Mesos on my machine and I
>> install neither of them to avoid conflicts. If I develop a module for a
>> particular Mesos version (i.e. build), I would like to use artifacts of
>> that build without installing them anywhere.
> 
> That's a valid use case. How about "installing" the 3rdparty packages
> by setting their $PREFIX to $(top_builddir)/3rdparty? That way, one
> can append "-I$(top_builddir)/3rdparty/include" to CPPFLAGS and
> "$(top_builddir)/3rdparty/lib" to their LD_LIBRARY_PATH when building
> modules? We can also update libprocess/Mesos to also use these
> locations instead of passing a dozen "-I" and "-L" flags during
> compilation. I am guessing this won't be too intrusive to the overall
> build system.
> 
>> Second, additionally 3rdparty packages, how about modules we provide with
>> Mesos, e.g. FixedResourceEstimator? Also if in the future we decide to
>> refactor default implementations into modules (e.g. hierarchical
>> allocator), we should install them somewhere.
> 
> We have a ticket (https://issues.apache.org/jira/browse/MESOS-1940)
> for it :-). We should just install them in $(pkglibdir).

My changes in MESOS-3608 install them into a new directory $pkgmoduledir based 
on review feedback. $pkgmoduledir is $pkglibdir/modules. My patch installs 
compatibility symlinks from $libdir for people who have configuration using the 
existing modules.

> That's the
> default location for distro packaging as well. That's not too hard to
> do. Just that we need to decide which modules should be installed.
> 
> Best,
> Kapil
> 
> 
>> On Wed, Jan 20, 2016 at 8:09 AM, Kapil Arya  wrote:
>> 
>>> On Wed, Jan 20, 2016 at 2:04 AM, Marco Massenzio 
>>> wrote:
 Great thinking, Kapil!
 (I'm one who got the headache :)
 
 However, having recently gone through the effort of having to figure out
>>> it
 all, my +1 goes for *good documentation* of what is necessary.
>>> 
>>> Totally with you on this :)
>>> 
>>> 
 When installing stuff / magic happening behind the scenes, it is always
 difficult to ensure it works on all "supported" platforms (and let's not
 even go into non-supported ones) and we would also run the risk that
>>> future
 changes may inadvertently break it.
 
 Bear also in mind that folks (who may not be using the --prefix) may be
 "surprised" to find incompatible/unexpected versions of
>>> glog/protobuf/etc.
 in the /usr/local system dir.
>>> 
>>> This is the reason why we want to put it inside Mesos "owned"
>>> directories (e.g., /usr/local/include/mesos/3rdparty,
>>> /usr/lib64/mesos/3rdparty) so that this whole operation is side-effect
>>> free for other applications/packages installed on the system.
>>> 
 We could also provide "exemplary scripts" that automate (most of) the
 tedious work and example build files, alongside documentation.
 If folks agree that this is a desirable alternative, I'm happy to help
>>> out
 - as mentioned, I've recently been through this, so memory is still
>>> fresh.
>>> 
>>> I think several of us have developed such scripts by now. However, the
>>> problem is maintainability as they get out-of-sync whenever a 3rdparty
>>> component is updated in Mesos :-/.
>>> 
 
 My 2c.
 
 --
 *Marco Massenzio*
 http://codetrips.com
 
 On Tue, Jan 19, 2016 at 10:22 PM, Kapil Arya 
>>> wrote:
 
> On Tue, Jan 19, 2016 at 11:58 PM, James Peach  wrote:
>> 
>>> On Jan 19, 2016, at 2:03 PM, Kapil Arya  wrote:
>>> 
>>> Hi All,
>>> 
>>> I wanted to get your opinion on installing the 3rdparty packages
>>> glog,
>>> protobuf, boost and picojson[1] when installing Mesos itself. These
>>> packages are required to build Mesos modules.
>> 
>> An alternative approach could be to hide these headers so they are
> internal to Mesos and not incidentally required by innocent modules.
>>> IIRC
> this should be fairly easy for picojson, but (much) harder for glog,
> protobuf and boost.
> 
> That's a lot of work and super hard to maintain IMHO :(.
> 
>>> Currently, a module write has to manually install these 3rdparty
>>> packages, either system-wide or locally, and update the compilation
>>> flags such as CPPFLAGS to point to the installation which is
>>> error-prone. Further, one might have a system-wide installation with
>>> the wrong package version, causing even more headache.
>> 
>> If you are looking at this, could you please also look at these:
>>

Re: Need a shepherd for MESOS--3317

2016-01-26 Thread Abhishek Dasgupta 

Vinod, Can you point me someone whom I can ask for the review?

On Wednesday 27 January 2016 12:07 AM, Vinod Kone wrote:

Sorry Abhishek, I don't have cycles :(

On Tue, Jan 26, 2016 at 3:18 AM, Abhishek Dasgupta <
a10gu...@linux.vnet.ibm.com> wrote:


Hi Vinod,

Can you review the patch https://reviews.apache.org/r/42794/ ? Or, if you
can delegate someone else to review the patch. This is my first review
request in mesos. Thank you.


On Thursday 21 January 2016 03:11 PM, Abhishek Dasgupta wrote:


Hi,

Can anybody please shepherd for
https://issues.apache.org/jira/browse/MESOS-3317 ?



--
   Regards,


---
   Abhishek Dasgupta
   Linux Software Developer - Linux Technology Centre
   IBM Systems Lab,
   IBM India Pvt. Ltd.
   Embassy Golf Link, D Block
   Koramongala - Off Indiranagar Ring Road
   Bangalore - 560 071
   Mobile: +91-8884107981

---




--
  Regards,

  
---
  Abhishek Dasgupta
  Linux Software Developer - Linux Technology Centre
  IBM Systems Lab,
  IBM India Pvt. Ltd.
  Embassy Golf Link, D Block
  Koramongala - Off Indiranagar Ring Road
  Bangalore - 560 071
  Mobile: +91-8884107981
  
---

Re: Need a shepherd for MESOS--3317

2016-01-26 Thread Kapil Arya 
Hi Abhishek,

I can shepherd this for you. Please add me to the RR.

Kapil

On Wed, Jan 27, 2016 at 12:31 AM, Abhishek Dasgupta
 wrote:
> Vinod, Can you point me someone whom I can ask for the review?
>
>
> On Wednesday 27 January 2016 12:07 AM, Vinod Kone wrote:
>>
>> Sorry Abhishek, I don't have cycles :(
>>
>> On Tue, Jan 26, 2016 at 3:18 AM, Abhishek Dasgupta <
>> a10gu...@linux.vnet.ibm.com> wrote:
>>
>>> Hi Vinod,
>>>
>>> Can you review the patch https://reviews.apache.org/r/42794/ ? Or, if you
>>> can delegate someone else to review the patch. This is my first review
>>> request in mesos. Thank you.
>>>
>>>
>>> On Thursday 21 January 2016 03:11 PM, Abhishek Dasgupta wrote:
>>>
 Hi,

 Can anybody please shepherd for
 https://issues.apache.org/jira/browse/MESOS-3317 ?


>>> --
>>>Regards,
>>>
>>>
>>>
>>> ---
>>>Abhishek Dasgupta
>>>Linux Software Developer - Linux Technology Centre
>>>IBM Systems Lab,
>>>IBM India Pvt. Ltd.
>>>Embassy Golf Link, D Block
>>>Koramongala - Off Indiranagar Ring Road
>>>Bangalore - 560 071
>>>Mobile: +91-8884107981
>>>
>>>
>>> ---
>>>
>>>
>
> --
>   Regards,
>
>
> ---
>   Abhishek Dasgupta
>   Linux Software Developer - Linux Technology Centre
>   IBM Systems Lab,
>   IBM India Pvt. Ltd.
>   Embassy Golf Link, D Block
>   Koramongala - Off Indiranagar Ring Road
>   Bangalore - 560 071
>   Mobile: +91-8884107981
>
> ---
>

Re: Install some 3rdparty packages needed for building Mesos modules

2016-01-26 Thread Alex Rukletsov 
Kapil—

great your started this topic. I would like to add my 4¢ to the discussion.

First, I think we should support two use cases: installing 3rdparty
packages and exposing them in the local build. As a Mesos (module)
developer, I may have different versions of Mesos on my machine and I
install neither of them to avoid conflicts. If I develop a module for a
particular Mesos version (i.e. build), I would like to use artifacts of
that build without installing them anywhere.

Second, additionally 3rdparty packages, how about modules we provide with
Mesos, e.g. FixedResourceEstimator? Also if in the future we decide to
refactor default implementations into modules (e.g. hierarchical
allocator), we should install them somewhere.

On Wed, Jan 20, 2016 at 8:09 AM, Kapil Arya  wrote:

> On Wed, Jan 20, 2016 at 2:04 AM, Marco Massenzio 
> wrote:
> > Great thinking, Kapil!
> > (I'm one who got the headache :)
> >
> > However, having recently gone through the effort of having to figure out
> it
> > all, my +1 goes for *good documentation* of what is necessary.
>
> Totally with you on this :)
>
>
> > When installing stuff / magic happening behind the scenes, it is always
> > difficult to ensure it works on all "supported" platforms (and let's not
> > even go into non-supported ones) and we would also run the risk that
> future
> > changes may inadvertently break it.
> >
> > Bear also in mind that folks (who may not be using the --prefix) may be
> > "surprised" to find incompatible/unexpected versions of
> glog/protobuf/etc.
> > in the /usr/local system dir.
>
> This is the reason why we want to put it inside Mesos "owned"
> directories (e.g., /usr/local/include/mesos/3rdparty,
> /usr/lib64/mesos/3rdparty) so that this whole operation is side-effect
> free for other applications/packages installed on the system.
>
> > We could also provide "exemplary scripts" that automate (most of) the
> > tedious work and example build files, alongside documentation.
> > If folks agree that this is a desirable alternative, I'm happy to help
> out
> > - as mentioned, I've recently been through this, so memory is still
> fresh.
>
> I think several of us have developed such scripts by now. However, the
> problem is maintainability as they get out-of-sync whenever a 3rdparty
> component is updated in Mesos :-/.
>
> >
> > My 2c.
> >
> > --
> > *Marco Massenzio*
> > http://codetrips.com
> >
> > On Tue, Jan 19, 2016 at 10:22 PM, Kapil Arya 
> wrote:
> >
> >> On Tue, Jan 19, 2016 at 11:58 PM, James Peach  wrote:
> >> >
> >> >> On Jan 19, 2016, at 2:03 PM, Kapil Arya  wrote:
> >> >>
> >> >> Hi All,
> >> >>
> >> >> I wanted to get your opinion on installing the 3rdparty packages
> glog,
> >> >> protobuf, boost and picojson[1] when installing Mesos itself. These
> >> >> packages are required to build Mesos modules.
> >> >
> >> > An alternative approach could be to hide these headers so they are
> >> internal to Mesos and not incidentally required by innocent modules.
> IIRC
> >> this should be fairly easy for picojson, but (much) harder for glog,
> >> protobuf and boost.
> >>
> >> That's a lot of work and super hard to maintain IMHO :(.
> >>
> >> >> Currently, a module write has to manually install these 3rdparty
> >> >> packages, either system-wide or locally, and update the compilation
> >> >> flags such as CPPFLAGS to point to the installation which is
> >> >> error-prone. Further, one might have a system-wide installation with
> >> >> the wrong package version, causing even more headache.
> >> >
> >> > If you are looking at this, could you please also look at these:
> >> > https://issues.apache.org/jira/browse/MESOS-2537
> >> > https://issues.apache.org/jira/browse/MESOS-4096
> >> >
> >> > MESOS-2537 provides consistent behaviour for building against
> optionally
> >> bundled dependencies (and fixes the --enable-foo semantics).
> >>
> >> I'll take a look at this one.
> >>
> >> > MESOS-4096 makes it impossible to run stout tests against a protobuf
> >> that is not version 2.5.0.
> >>
> >> At some point, AlexR and I tried to work on it, but with the stout
> >> directory structure, it got harder to fix then it seemed at first.
> >>
> >> >
> >> >> The proposal here is to install these 3rdparty packages when
> >> >> installing Mesos. To avoid any conflicts with system-wide or local
> >> >> installation, we can install them as follows:
> >> >>
> >> >> ${PREFIX}/include/mesos/3rdparty -- for header files
> >> >> ${PREFIX}//mesos/3rdparty -- for library files (LIBDIR can be
> >> >> lib or lib64 depending upon the installation)
> >> >>
> >> >> where PREFIX refers to the `--prefix` flag for Mesos configure
> script.
> >> >>
> >> >> We would then update `mesos.pc` with the correct flags so that a
> >> >> module write can simply use `pkg-config` to get all the required
> >> >> flags.
> >> >>
> >> >> I have created an issue
> >> >>

Re: Mesos 0.27.0 release update

2016-01-26 Thread tommy xiao 
try master branch, make check on macos 10.11.2

[ RUN  ] SubcommandTest.Dispatch

Subcommand 'subcommand' is not available

Usage: command  [OPTIONS]


Available subcommands:

help

subcommand2


Multiple subcommands have name 'subcommand'

[   OK ] SubcommandTest.Dispatch (0 ms)

[--] 2 tests from SubcommandTest (1 ms total)


[--] 2 tests from SVNTest

[ RUN  ] SVNTest.DiffPatch

*** Aborted at 1453828980 (unix time) try "date -d @1453828980" if you are
using GNU date ***

PC: @0x10838b219 apr_pool_create_ex

*** SIGSEGV (@0x30) received by PID 734 (TID 0x7fff79de2000) stack trace:
***

@ 0x7fff897afeaa _sigtramp

@ 0x7fff650d7492 (unknown)

@0x10820f22d svn_pool_create_ex

@0x107910bde svn::diff()

@0x10790f4a9 SVNTest_DiffPatch_Test::TestBody()

@0x107988223
testing::internal::HandleSehExceptionsInMethodIfSupported<>()

@0x10796c377
testing::internal::HandleExceptionsInMethodIfSupported<>()

@0x10792c2e5 testing::Test::Run()

@0x10792d82b testing::TestInfo::Run()

@0x10792e4c7 testing::TestCase::Run()

@0x10793cca3 testing::internal::UnitTestImpl::RunAllTests()

@0x10798b2c3
testing::internal::HandleSehExceptionsInMethodIfSupported<>()

@0x10796e9b7
testing::internal::HandleExceptionsInMethodIfSupported<>()

@0x10793c8a0 testing::UnitTest::Run()

@0x107789da1 RUN_ALL_TESTS()

@0x107789d80 main

@ 0x7fff9c14c5ad start

@0x1 (unknown)

make[7]: *** [check-local] Segmentation fault: 11

make[6]: *** [check-am] Error 2

make[5]: *** [check-recursive] Error 1

make[4]: *** [check] Error 2

make[3]: *** [check-recursive] Error 1

make[2]: *** [check-recursive] Error 1

make[1]: *** [check] Error 2

make: *** [check-recursive] Error 1



2016-01-26 7:38 GMT+08:00 Timothy Chen :

> We're creating a release from latest master this as soon as the
> remaining two blockers are resolved, current estimate should be
> tomorrow.
>
> Please go ahead and try out the latest master if you can.
>
> Thanks!
>
> Tim
>
> On Mon, Jan 25, 2016 at 11:53 AM, Sarjeet Singh
>  wrote:
> > Thanks Bernd for confirming. This should fix this issue in Mesos 0.27.
> >
> > Any update on when this is planned to be released?
> >
> > -Sarjeet
> >
> > On Mon, Jan 25, 2016 at 10:40 AM, Bernd Mathiske 
> > wrote:
> >
> >> Hi Sarjeet,
> >>
> >> I hope we fixed this in upcoming 0.27:
> >>
> >> https://issues.apache.org/jira/browse/MESOS-4304
> >>
> >> Bernd
> >>
> >> On Jan 25, 2016, at 7:30 PM, Sarjeet Singh 
> >> wrote:
> >>
> >> I ran into an issue when tried Mesos 0.26 version and started a marathon
> >> app using URI (with maprfs path) on a mesos cluster.
> >>
> >> The issue seems to be caused by Mesos-3602 fix, and is causing issue for
> >> maprfs (mapr filesystem) when specified maprfs path as URI on marathon.
> >>
> >> The issue is that, It is appending '/' to the URI maprfs path
> specified, in
> >> the beginning, and is not executed as expected. e.g.
> >>
> >> =
> >> *  hadoop fs -copyToLocal '/
> >> maprfs:///dist/hadoop-2.7.0.myriad1.tar.gz'
> >>
> >>
> '/opt/mapr/slaves/67d1f64c-449b-4609-82f3-5da309f3c5c5-S9/frameworks/67d1f64c-449b-4609-82f3-5da309f3c5c5-/executors/myriad1.63bbb98c-c072-11e5-b686-0cc47a587d20/runs/427fe309-82c5-4f8b-9fa3-6dd39a4a5ef4/hadoop-2.7.0.myriad1.tar.gz*
> >>
> >>
> >> -copyToLocal: java.net.URISyntaxException: Expected scheme-specific
> part at
> >> index 7: maprfs:
> >> =
> >>
> >> The fix for Mesos-3602 only assumes hdfs path, and doesn't consider
> other
> >> cases, such as maprfs or other dfs paths. I haven't filed a JIRA yet on
> >> this issue, but would like to get some feedback on this, and expect
> this to
> >> be fixed for next Mesos release.
> >>
> >> Let me know if there is anything else I could provide related to the
> issue.
> >>
> >> -Sarjeet
> >>
> >> On Sat, Jan 23, 2016 at 12:41 AM, Timothy Chen 
> wrote:
> >>
> >> Hi all,
> >>
> >> (Kapil, MPark and I) We're still having 3 blocker issues outstanding
> >> at this moment:
> >>
> >> MESOS-4449: SegFault on agent during executor startup (shepherd: Joris)
> >> MESOS-4441: Do not allocate non-revocable resources beyond quota
> >> guarantee. (shepherd: Joris)
> >> MESOS-4410: Introduce protobuf for quota set request. (shepherd: Joris)
> >>
> >> The remaining major tickets are ContainerLogger related and should be
> >> committed today according to Ben.
> >>
> >> We've started to test latest master and will be looking at the test
> >> failures to see what needs to be addressed.
> >>
> >> I encourage everyone to test the latest master on your platform if
> >> possible to catch issues early, and once the Blocker issues are
> >> resolved we'll be sending a RC to test and

Re: Mesos 0.27.0 release update

2016-01-26 Thread Alex Rukletsov 
This looks new. Is it reproducible? Could you please file a JIRA for it to
track properly?

On Tue, Jan 26, 2016 at 6:26 PM, tommy xiao  wrote:

> try master branch, make check on macos 10.11.2
>
> [ RUN  ] SubcommandTest.Dispatch
>
> Subcommand 'subcommand' is not available
>
> Usage: command  [OPTIONS]
>
>
> Available subcommands:
>
> help
>
> subcommand2
>
>
> Multiple subcommands have name 'subcommand'
>
> [   OK ] SubcommandTest.Dispatch (0 ms)
>
> [--] 2 tests from SubcommandTest (1 ms total)
>
>
> [--] 2 tests from SVNTest
>
> [ RUN  ] SVNTest.DiffPatch
>
> *** Aborted at 1453828980 (unix time) try "date -d @1453828980" if you are
> using GNU date ***
>
> PC: @0x10838b219 apr_pool_create_ex
>
> *** SIGSEGV (@0x30) received by PID 734 (TID 0x7fff79de2000) stack trace:
> ***
>
> @ 0x7fff897afeaa _sigtramp
>
> @ 0x7fff650d7492 (unknown)
>
> @0x10820f22d svn_pool_create_ex
>
> @0x107910bde svn::diff()
>
> @0x10790f4a9 SVNTest_DiffPatch_Test::TestBody()
>
> @0x107988223
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
>
> @0x10796c377
> testing::internal::HandleExceptionsInMethodIfSupported<>()
>
> @0x10792c2e5 testing::Test::Run()
>
> @0x10792d82b testing::TestInfo::Run()
>
> @0x10792e4c7 testing::TestCase::Run()
>
> @0x10793cca3 testing::internal::UnitTestImpl::RunAllTests()
>
> @0x10798b2c3
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
>
> @0x10796e9b7
> testing::internal::HandleExceptionsInMethodIfSupported<>()
>
> @0x10793c8a0 testing::UnitTest::Run()
>
> @0x107789da1 RUN_ALL_TESTS()
>
> @0x107789d80 main
>
> @ 0x7fff9c14c5ad start
>
> @0x1 (unknown)
>
> make[7]: *** [check-local] Segmentation fault: 11
>
> make[6]: *** [check-am] Error 2
>
> make[5]: *** [check-recursive] Error 1
>
> make[4]: *** [check] Error 2
>
> make[3]: *** [check-recursive] Error 1
>
> make[2]: *** [check-recursive] Error 1
>
> make[1]: *** [check] Error 2
>
> make: *** [check-recursive] Error 1
>
>
>
> 2016-01-26 7:38 GMT+08:00 Timothy Chen :
>
> > We're creating a release from latest master this as soon as the
> > remaining two blockers are resolved, current estimate should be
> > tomorrow.
> >
> > Please go ahead and try out the latest master if you can.
> >
> > Thanks!
> >
> > Tim
> >
> > On Mon, Jan 25, 2016 at 11:53 AM, Sarjeet Singh
> >  wrote:
> > > Thanks Bernd for confirming. This should fix this issue in Mesos 0.27.
> > >
> > > Any update on when this is planned to be released?
> > >
> > > -Sarjeet
> > >
> > > On Mon, Jan 25, 2016 at 10:40 AM, Bernd Mathiske 
> > > wrote:
> > >
> > >> Hi Sarjeet,
> > >>
> > >> I hope we fixed this in upcoming 0.27:
> > >>
> > >> https://issues.apache.org/jira/browse/MESOS-4304
> > >>
> > >> Bernd
> > >>
> > >> On Jan 25, 2016, at 7:30 PM, Sarjeet Singh  >
> > >> wrote:
> > >>
> > >> I ran into an issue when tried Mesos 0.26 version and started a
> marathon
> > >> app using URI (with maprfs path) on a mesos cluster.
> > >>
> > >> The issue seems to be caused by Mesos-3602 fix, and is causing issue
> for
> > >> maprfs (mapr filesystem) when specified maprfs path as URI on
> marathon.
> > >>
> > >> The issue is that, It is appending '/' to the URI maprfs path
> > specified, in
> > >> the beginning, and is not executed as expected. e.g.
> > >>
> > >> =
> > >> *  hadoop fs -copyToLocal '/
> > >> maprfs:///dist/hadoop-2.7.0.myriad1.tar.gz'
> > >>
> > >>
> >
> '/opt/mapr/slaves/67d1f64c-449b-4609-82f3-5da309f3c5c5-S9/frameworks/67d1f64c-449b-4609-82f3-5da309f3c5c5-/executors/myriad1.63bbb98c-c072-11e5-b686-0cc47a587d20/runs/427fe309-82c5-4f8b-9fa3-6dd39a4a5ef4/hadoop-2.7.0.myriad1.tar.gz*
> > >>
> > >>
> > >> -copyToLocal: java.net.URISyntaxException: Expected scheme-specific
> > part at
> > >> index 7: maprfs:
> > >> =
> > >>
> > >> The fix for Mesos-3602 only assumes hdfs path, and doesn't consider
> > other
> > >> cases, such as maprfs or other dfs paths. I haven't filed a JIRA yet
> on
> > >> this issue, but would like to get some feedback on this, and expect
> > this to
> > >> be fixed for next Mesos release.
> > >>
> > >> Let me know if there is anything else I could provide related to the
> > issue.
> > >>
> > >> -Sarjeet
> > >>
> > >> On Sat, Jan 23, 2016 at 12:41 AM, Timothy Chen 
> > wrote:
> > >>
> > >> Hi all,
> > >>
> > >> (Kapil, MPark and I) We're still having 3 blocker issues outstanding
> > >> at this moment:
> > >>
> > >> MESOS-4449: SegFault on agent during executor startup (shepherd:
> Joris)
> > >> MESOS-4441: Do not allocate non-revocable resources beyond quota
> > >> guarantee. (shepherd: Joris)
> > >> MESOS-4410: Introduce protobuf for

RE: IPv6 support in Mesos

2016-01-26 Thread Daniel Osborne 
Hi Benno,

I work on Project Calico, a networking plugin for Mesos that does 
IP-per-container and has support for IPv6.

Though I haven't contributed to any work in Mesos to support this, I'd like to 
be involved and am happy to assist in testing these patches.

Thanks,
Dan

-Original Message-
From: Evers Benno [mailto:ben...@yandex-team.ru] 
Sent: Monday, January 25, 2016 4:53 AM
To: dev@mesos.apache.org
Subject: IPv6 support in Mesos

Hello all,

We are currently planning to deploy a mesos cluster for internal use in 
Yandex.Maps.

Since the ability to work on IPv6-only hosts is necessary for us, we are 
planning to start working on the necessary patches in the coming weeks, and  to 
contribute our progress.

Work towards full IPv6 support apparently was started a year ago in
MESOS-1027 (https://issues.apache.org/jira/browse/MESOS-1027), but as far as I 
can tell, the last activity was in June 2015.

Is someone else currently working on this? Or did anyone work on this, and 
encounter unexpected difficulties?

If so, it would likely be a good idea to coordinate with each other, so we 
don't unnecessarily duplicate work and/or mistakes and bugs.

Best regards,
Benno Evers

Re: Need a shepherd for MESOS--3317

2016-01-26 Thread Vinod Kone 
Sorry Abhishek, I don't have cycles :(

On Tue, Jan 26, 2016 at 3:18 AM, Abhishek Dasgupta <
a10gu...@linux.vnet.ibm.com> wrote:

> Hi Vinod,
>
> Can you review the patch https://reviews.apache.org/r/42794/ ? Or, if you
> can delegate someone else to review the patch. This is my first review
> request in mesos. Thank you.
>
>
> On Thursday 21 January 2016 03:11 PM, Abhishek Dasgupta wrote:
>
>> Hi,
>>
>> Can anybody please shepherd for
>> https://issues.apache.org/jira/browse/MESOS-3317 ?
>>
>>
> --
>   Regards,
>
>
> ---
>   Abhishek Dasgupta
>   Linux Software Developer - Linux Technology Centre
>   IBM Systems Lab,
>   IBM India Pvt. Ltd.
>   Embassy Golf Link, D Block
>   Koramongala - Off Indiranagar Ring Road
>   Bangalore - 560 071
>   Mobile: +91-8884107981
>
> ---
>
>

Re: Install some 3rdparty packages needed for building Mesos modules

2016-01-26 Thread Kapil Arya 
Thanks for the feedback, Alex! I have inlined my responses.

> First, I think we should support two use cases: installing 3rdparty
> packages and exposing them in the local build. As a Mesos (module)
> developer, I may have different versions of Mesos on my machine and I
> install neither of them to avoid conflicts. If I develop a module for a
> particular Mesos version (i.e. build), I would like to use artifacts of
> that build without installing them anywhere.

That's a valid use case. How about "installing" the 3rdparty packages
by setting their $PREFIX to $(top_builddir)/3rdparty? That way, one
can append "-I$(top_builddir)/3rdparty/include" to CPPFLAGS and
"$(top_builddir)/3rdparty/lib" to their LD_LIBRARY_PATH when building
modules? We can also update libprocess/Mesos to also use these
locations instead of passing a dozen "-I" and "-L" flags during
compilation. I am guessing this won't be too intrusive to the overall
build system.

> Second, additionally 3rdparty packages, how about modules we provide with
> Mesos, e.g. FixedResourceEstimator? Also if in the future we decide to
> refactor default implementations into modules (e.g. hierarchical
> allocator), we should install them somewhere.

We have a ticket (https://issues.apache.org/jira/browse/MESOS-1940)
for it :-). We should just install them in $(pkglibdir). That's the
default location for distro packaging as well. That's not too hard to
do. Just that we need to decide which modules should be installed.

Best,
Kapil


> On Wed, Jan 20, 2016 at 8:09 AM, Kapil Arya  wrote:
>
>> On Wed, Jan 20, 2016 at 2:04 AM, Marco Massenzio 
>> wrote:
>> > Great thinking, Kapil!
>> > (I'm one who got the headache :)
>> >
>> > However, having recently gone through the effort of having to figure out
>> it
>> > all, my +1 goes for *good documentation* of what is necessary.
>>
>> Totally with you on this :)
>>
>>
>> > When installing stuff / magic happening behind the scenes, it is always
>> > difficult to ensure it works on all "supported" platforms (and let's not
>> > even go into non-supported ones) and we would also run the risk that
>> future
>> > changes may inadvertently break it.
>> >
>> > Bear also in mind that folks (who may not be using the --prefix) may be
>> > "surprised" to find incompatible/unexpected versions of
>> glog/protobuf/etc.
>> > in the /usr/local system dir.
>>
>> This is the reason why we want to put it inside Mesos "owned"
>> directories (e.g., /usr/local/include/mesos/3rdparty,
>> /usr/lib64/mesos/3rdparty) so that this whole operation is side-effect
>> free for other applications/packages installed on the system.
>>
>> > We could also provide "exemplary scripts" that automate (most of) the
>> > tedious work and example build files, alongside documentation.
>> > If folks agree that this is a desirable alternative, I'm happy to help
>> out
>> > - as mentioned, I've recently been through this, so memory is still
>> fresh.
>>
>> I think several of us have developed such scripts by now. However, the
>> problem is maintainability as they get out-of-sync whenever a 3rdparty
>> component is updated in Mesos :-/.
>>
>> >
>> > My 2c.
>> >
>> > --
>> > *Marco Massenzio*
>> > http://codetrips.com
>> >
>> > On Tue, Jan 19, 2016 at 10:22 PM, Kapil Arya 
>> wrote:
>> >
>> >> On Tue, Jan 19, 2016 at 11:58 PM, James Peach  wrote:
>> >> >
>> >> >> On Jan 19, 2016, at 2:03 PM, Kapil Arya  wrote:
>> >> >>
>> >> >> Hi All,
>> >> >>
>> >> >> I wanted to get your opinion on installing the 3rdparty packages
>> glog,
>> >> >> protobuf, boost and picojson[1] when installing Mesos itself. These
>> >> >> packages are required to build Mesos modules.
>> >> >
>> >> > An alternative approach could be to hide these headers so they are
>> >> internal to Mesos and not incidentally required by innocent modules.
>> IIRC
>> >> this should be fairly easy for picojson, but (much) harder for glog,
>> >> protobuf and boost.
>> >>
>> >> That's a lot of work and super hard to maintain IMHO :(.
>> >>
>> >> >> Currently, a module write has to manually install these 3rdparty
>> >> >> packages, either system-wide or locally, and update the compilation
>> >> >> flags such as CPPFLAGS to point to the installation which is
>> >> >> error-prone. Further, one might have a system-wide installation with
>> >> >> the wrong package version, causing even more headache.
>> >> >
>> >> > If you are looking at this, could you please also look at these:
>> >> > https://issues.apache.org/jira/browse/MESOS-2537
>> >> > https://issues.apache.org/jira/browse/MESOS-4096
>> >> >
>> >> > MESOS-2537 provides consistent behaviour for building against
>> optionally
>> >> bundled dependencies (and fixes the --enable-foo semantics).
>> >>
>> >> I'll take a look at this one.
>> >>
>> >> > MESOS-4096 makes it impossible to run stout tests against a protobuf
>> >> that is not version 2.5.0.

Re: JIRA Shepherds

2016-01-26 Thread Vaibhav Khanduja 
The community is growing with more individuals getting interested in
contributing to the project. This definitely brings an extra bit of
workload for committers “Shepherds” but at the same time more developers
eventually leads more adoptability across organization and enterprises.



I am not sure if this is easy to find an immediate solution but would
really like some sort of resolution on this. If shepherd is busy, what else
can be done for a low priority but a genuine issue.

On Sun, Jan 24, 2016 at 4:12 PM, Joris Van Remoortere <
joris.van.remoort...@gmail.com> wrote:

> Hello Mesos developers,
>
> You may have noticed some churn in Jira recently around the shepherd
> assignment. Specifically, we have unassigned the shepherds for a bunch of
> projects. We did this in order to get a better sense of which projects are
> being actively shepherded versus having gone stale, and to identify for
> which projects we need to find a new shepherd who has sufficient time to
> dedicate to it.
>
> This is not a statement that the un-assigned tickets are not important,
> rather, we want to ensure that the people working on them have a shepherd
> with sufficient resources.
>
> We ask that you communicate (and agree!) with your shepherd before
> assigning them in Jira, so that they are not surprised when you reviews
> start getting posted.
>
> The benefit for the developer community should be that it will be more
> clear when working on a ticket whether there are sufficient resources in
> the community to iterate on it in a timely manner.
>
> Joris
>