Question about "Framework directly access Meso agent"

[Suteng]

Hi,

Currently, Mesos framework's task related operations lauchTask, updateStatus 
and executorSendMessage etc., and resource related operations resourceOffer 
etc., all operations are pass through Mesos Master.
When the cluster and task number become huge, or with optimistic resource 
offer, multi-framework concurrently launchTask, maybe Mesos Master will be a 
bottleneck.
Is possible for framework scheduler directly access Mesos agent, launchTask, 
updateStatus and SendMessage2Executore to Mesos Agent directly, bypass the 
Master?
Will invoke big conflict with current mechanism?

Looking forward to your comments and opinions.

Best Regards,
Teng


[cid:image001.png@01D16976.1DFAFB20]


Su Teng  00241668


Distributed and Parallel Software Lab
Huawei Technologies Co., Ltd.
Email:sut...@huawei.com

[VOTE] Release Apache Mesos 0.27.1 (rc1)

[Michael Park]

Hi all,

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


0.27.1 includes the following:

* Improved `systemd` integration.
* Ability to disable `systemd` integration.

* Additional performance improvements to /state endpoint.
* Removed duplicate "active" keys from the /state endpoint.

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.1-rc1


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

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

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

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.27.1-rc1/mesos-0.27.1.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-1102

Please vote on releasing this package as Apache Mesos 0.27.1!

The vote is open until Fri Feb 19 17:00:00 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.1
[ ] -1 Do not release this package because ...

Thanks,

Joris, MPark

Re: Reorganize 3rdparty directory

[Kapil Arya]

Thanks for bringing it up Alexander!

I don't have a strong opinion wrt git submodules since I don't have
much experience with them personally. Having said that, I would like
to go conservative on this one (baby steps :-) ).

Further, I do understand that moving libprocess and stout directories
will be painful for people who already have several branches and will
have conflicts. But I do think, there are some interim solutions as
well (for example, move libprocess/stout to wherever we want, but keep
a symlink from 3rdparty/libprocess, etc, to those new locations for
some time). I am sure there are better solutions out there, but this
should work too.

Best,
Kapil

On Tue, Feb 16, 2016 at 12:38 PM, Erik Weathers
 wrote:
> If we go to git submodules, please ensure there are good docs around how to
> update cloned repos.
>
> e.g., From ansible: https://docs.ansible.com/ansible/intro_installation.html
>
> Note when updating ansible, be sure to not only update the source tree, but
> also the “submodules” in git which point at Ansible’s own modules (not the
> same kind of modules, alas).
>
> $ git pull --rebase
> $ git submodule update --init --recursive
>
> Thanks,
>
> - Erik
>
> On Tue, Feb 16, 2016 at 8:54 AM, Alexander Rojas 
> wrote:
>
>> +1
>> I am one who is totally in for that change. It is not only the directories
>> problem, but the structure which has led that the stout tests (which do
>> need to be compiled) are actually managed in the libprocess Makefile, on
>> top of all the things you have already mentioned.
>>
>>
>> > On 09 Feb 2016, at 17:53, Kapil Arya  wrote:
>> >
>> > On Tue, Feb 9, 2016 at 8:23 PM, Jie Yu  wrote:
>> >> Kapil,
>> >>
>> >> I guess what I want to understand is why the existing structure makes it
>> >> hard for you to do the things that you want to do (installing
>> >> module-specific 3rdparty dependencies into "${pkglibdir}/3rdparty" as
>> part
>> >> of "make install").
>> >
>> > Let me see if I can answer that :-).
>> >
>> > This is somewhat related. For example, if we want to install protobuf
>> > in 3rdparty/{include,lib} (for module developers to use them without
>> > doing a proper mesos installation), you need to provide the correct
>> > "--prefix" flag that points to 3rdparty/. However, due to multiple
>> > levels of configure.ac, the "--prefix" can at best be generated by
>> > prepending "../../../" to get to the great-grandparent directory. This
>> > is because we have a separate configure.ac which manages
>> > 3rdparty/libprocess/3rdparty/Makefile.am. There are ways around it,
>> > but they are not clean.
>> >
>> > Similar thing holds for system-wide installation of these 3rdparty
>> > packages. For example, ideally, we would want to use
>> > "${pkglibdir}/3rdparty" as a prefix for those packages. However, since
>> > they are part of libprocess package, we don't get the correct
>> > directory and have to use either hardwired $pkglibdir, or somehow pass
>> > it from the top-level configure all the way down to
>> > 3rdparty/libprocess/3rdparty/Makefile.am :-(.
>> >
>> >
>> >> The only reason you mentioned in the original email is that "in the
>> current
>> >> code base, we don't strictly follow the 3rdparty structure", which IMO
>> is
>> >> not a very convincing reason for such a big change.
>> >
>> > How about a not so big change? :-). What if we just move
>> > 3rdparty/libprocess/3rdparty/* stuff out to 3rdparty/ while leaving
>> > stout as is? That is not a big change since we are not touching
>> > libprocess/stout. Just adjusting Makefiles and I am pretty sure it
>> > will be cleaner and simpler than what we have right now.
>> >
>> > As a later time, we can then consider moving stout out to 3rdparty/
>> > while leaving libprocess as is. But that's something we can decide
>> > later and leave stout as an exception for now.
>> >
>> > BTW, if we were to install all the 3rdparty packages in 3rdparty/,
>> > that would also cut down a lot on the compiler flags (i.e., fewer "-I"
>> > and "-L" flags) :-).
>> >
>> > Kapil
>> >
>> >>
>> >> - Jie
>> >>
>> >> On Tue, Feb 9, 2016 at 5:04 PM, Kapil Arya  wrote:
>> >>
>> >>> On Tue, Feb 9, 2016 at 7:20 PM, Jie Yu  wrote:
>> 
>> >
>> > However, in the current code base, we don't strictly follow the
>> >>> 3rdparty
>> > structure. For example, stout has a dependency on picojson and
>> > google-protobuf, but we don't put these two packages inside
>> > 3rdparty/libprocess/3rdparty/stout/3rdparty/.
>> 
>> 
>>  My understanding is that stout is header only. So it does not have to
>>  bundle 3rdparty libraries. The user of stout is responsible for
>> bundling
>>  them if they are used.
>> >>>
>> >>>
>> >>> I don't think being header-only is an excuse to have a broken
>> >>> installation :-). Further, we don't make it easier for the user to get
>> >>> the 

Re: Reorganize 3rdparty directory

[Erik Weathers]

If we go to git submodules, please ensure there are good docs around how to
update cloned repos.

e.g., From ansible: https://docs.ansible.com/ansible/intro_installation.html

Note when updating ansible, be sure to not only update the source tree, but
also the “submodules” in git which point at Ansible’s own modules (not the
same kind of modules, alas).

$ git pull --rebase
$ git submodule update --init --recursive

Thanks,

- Erik

On Tue, Feb 16, 2016 at 8:54 AM, Alexander Rojas 
wrote:

> +1
> I am one who is totally in for that change. It is not only the directories
> problem, but the structure which has led that the stout tests (which do
> need to be compiled) are actually managed in the libprocess Makefile, on
> top of all the things you have already mentioned.
>
>
> > On 09 Feb 2016, at 17:53, Kapil Arya  wrote:
> >
> > On Tue, Feb 9, 2016 at 8:23 PM, Jie Yu  wrote:
> >> Kapil,
> >>
> >> I guess what I want to understand is why the existing structure makes it
> >> hard for you to do the things that you want to do (installing
> >> module-specific 3rdparty dependencies into "${pkglibdir}/3rdparty" as
> part
> >> of "make install").
> >
> > Let me see if I can answer that :-).
> >
> > This is somewhat related. For example, if we want to install protobuf
> > in 3rdparty/{include,lib} (for module developers to use them without
> > doing a proper mesos installation), you need to provide the correct
> > "--prefix" flag that points to 3rdparty/. However, due to multiple
> > levels of configure.ac, the "--prefix" can at best be generated by
> > prepending "../../../" to get to the great-grandparent directory. This
> > is because we have a separate configure.ac which manages
> > 3rdparty/libprocess/3rdparty/Makefile.am. There are ways around it,
> > but they are not clean.
> >
> > Similar thing holds for system-wide installation of these 3rdparty
> > packages. For example, ideally, we would want to use
> > "${pkglibdir}/3rdparty" as a prefix for those packages. However, since
> > they are part of libprocess package, we don't get the correct
> > directory and have to use either hardwired $pkglibdir, or somehow pass
> > it from the top-level configure all the way down to
> > 3rdparty/libprocess/3rdparty/Makefile.am :-(.
> >
> >
> >> The only reason you mentioned in the original email is that "in the
> current
> >> code base, we don't strictly follow the 3rdparty structure", which IMO
> is
> >> not a very convincing reason for such a big change.
> >
> > How about a not so big change? :-). What if we just move
> > 3rdparty/libprocess/3rdparty/* stuff out to 3rdparty/ while leaving
> > stout as is? That is not a big change since we are not touching
> > libprocess/stout. Just adjusting Makefiles and I am pretty sure it
> > will be cleaner and simpler than what we have right now.
> >
> > As a later time, we can then consider moving stout out to 3rdparty/
> > while leaving libprocess as is. But that's something we can decide
> > later and leave stout as an exception for now.
> >
> > BTW, if we were to install all the 3rdparty packages in 3rdparty/,
> > that would also cut down a lot on the compiler flags (i.e., fewer "-I"
> > and "-L" flags) :-).
> >
> > Kapil
> >
> >>
> >> - Jie
> >>
> >> On Tue, Feb 9, 2016 at 5:04 PM, Kapil Arya  wrote:
> >>
> >>> On Tue, Feb 9, 2016 at 7:20 PM, Jie Yu  wrote:
> 
> >
> > However, in the current code base, we don't strictly follow the
> >>> 3rdparty
> > structure. For example, stout has a dependency on picojson and
> > google-protobuf, but we don't put these two packages inside
> > 3rdparty/libprocess/3rdparty/stout/3rdparty/.
> 
> 
>  My understanding is that stout is header only. So it does not have to
>  bundle 3rdparty libraries. The user of stout is responsible for
> bundling
>  them if they are used.
> >>>
> >>>
> >>> I don't think being header-only is an excuse to have a broken
> >>> installation :-). Further, we don't make it easier for the user to get
> >>> the 3rdparty binaries either. For example, if the user has a different
> >>> version of protobuf installed on the system, the compilation of any
> >>> program that uses stout will fail spectacularly!
> >>>
> >>> Having said that, the gist here is that we have somewhat deviated from
> >>> original motivation behind the 3rdparty directory and it would be nice
> >>> if we can have a flatter structure.
> >>>
> 
> 
>  - Jie
> 
>  On Tue, Feb 9, 2016 at 4:14 PM, Kapil Arya 
> wrote:
> 
> > Hi All,
> >
> > TLDR: Move everything from 3rdparty/libprocess/3rdparty/* into
> >>> 3rdparty/.
> > (Optionally) Move libprocess/stout to the top-level directory.
> >
> > I wanted to start some discussion around reorganizing stuff inside
> > "3rdparty". I apologize for the length of the email, please bear with
> >>> 

Re: Inconsistent naming of support scripts

[Vinod Kone]

Thanks for the feedback. I'll send out a patch.

On Tue, Feb 16, 2016 at 9:12 AM, haosdent  wrote:

> >running `find /usr/local/bin -name "*-*" | wc -l` returned 142 while `find
> /usr/local/bin -name "*_*" | wc -l` was only 17. So I feel using hyphen for
> executables is more standard.
>
> +1 Same for me.
>
> On Wed, Feb 17, 2016 at 1:10 AM, Alexander Rojas 
> wrote:
>
> > +1 for consistency, +1 for executables.
> >
> > I do enough finger yoga while using emacs!
> >
> > running `find /usr/local/bin -name "*-*" | wc -l` returned 142 while
> `find
> > /usr/local/bin -name "*_*" | wc -l` was only 17. So I feel using hyphen
> for
> > executables is more standard.
> >
> > > On 11 Feb 2016, at 14:58, Michael Park  wrote:
> > >
> > > +1 for consistency, +1 for hyphens for executables.
> > >
> > > On 11 February 2016 at 14:25, Kevin Klues  wrote:
> > >
> > >> I typically think of files having dashes as binaries or scripts that
> > >> are runnable, whereas files with underscores are meant as source or
> > >> otherwise supplementary to the binary produced (e.g. a supplementary
> > >> python library that the main python program imports).  I'm  not sure
> > >> where I inherited this convention from, but it's always been the way
> > >> I've done things.
> > >>
> > >> As far as our code base goes, we seem to use this convention as well
> > >> with our mesos-master.sh. mesos-slave.sh, etc. binaries.
> > >>
> > >> On Thu, Feb 11, 2016 at 2:17 PM, Vinod Kone 
> > wrote:
> > >>> Why hyphens? Most of the files in our repo use underscores. I would
> > like
> > >> us
> > >>> to be consistent on how we name files in the repo.
> > >>>
> > >>> On Thu, Feb 11, 2016 at 1:40 PM, Kevin Klues 
> > wrote:
> > >>>
> >  I prefer hyphens as well
> > 
> >  On Thu, Feb 11, 2016 at 1:28 PM, Jojy Varghese 
> > >> wrote:
> > > hyphen++. Is google friendly apparently.  Also less keys to press
> :)
> > >
> > > -Jojy
> > >
> > >
> > >
> > >> On Feb 11, 2016, at 12:43 PM, Greg Mann 
> wrote:
> > >>
> > >> +1
> > >>
> > >> On Thu, Feb 11, 2016 at 11:41 AM, Vinod Kone <
> vinodk...@apache.org>
> >  wrote:
> > >>
> > >>> Some the scripts in the "support" directory have dashes ("-") in
> > >> their
> > >>> names (e.g., apply-review.sh, apply-reviews.py), whereas some
> have
> > >>> underscores ("_") (e.g., docker_build.sh, mesos_split.py).
> > >>>
> > >>> This is really confusing and we should stick with one style. I
> > >> propose
> >  to
> > >>> change all them to use underscores. I will make sure the CI jobs
> > are
> > >>> updated accordingly.
> > >>>
> > >>> Any objections?
> > >>>
> > >>> Thanks,
> > >>> Vinod
> > >>>
> > >
> > 
> > 
> > 
> >  --
> >  ~Kevin
> > 
> > >>
> > >>
> > >>
> > >> --
> > >> ~Kevin
> > >>
> >
> >
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Inconsistent naming of support scripts

[haosdent]

>running `find /usr/local/bin -name "*-*" | wc -l` returned 142 while `find
/usr/local/bin -name "*_*" | wc -l` was only 17. So I feel using hyphen for
executables is more standard.

+1 Same for me.

On Wed, Feb 17, 2016 at 1:10 AM, Alexander Rojas 
wrote:

> +1 for consistency, +1 for executables.
>
> I do enough finger yoga while using emacs!
>
> running `find /usr/local/bin -name "*-*" | wc -l` returned 142 while `find
> /usr/local/bin -name "*_*" | wc -l` was only 17. So I feel using hyphen for
> executables is more standard.
>
> > On 11 Feb 2016, at 14:58, Michael Park  wrote:
> >
> > +1 for consistency, +1 for hyphens for executables.
> >
> > On 11 February 2016 at 14:25, Kevin Klues  wrote:
> >
> >> I typically think of files having dashes as binaries or scripts that
> >> are runnable, whereas files with underscores are meant as source or
> >> otherwise supplementary to the binary produced (e.g. a supplementary
> >> python library that the main python program imports).  I'm  not sure
> >> where I inherited this convention from, but it's always been the way
> >> I've done things.
> >>
> >> As far as our code base goes, we seem to use this convention as well
> >> with our mesos-master.sh. mesos-slave.sh, etc. binaries.
> >>
> >> On Thu, Feb 11, 2016 at 2:17 PM, Vinod Kone 
> wrote:
> >>> Why hyphens? Most of the files in our repo use underscores. I would
> like
> >> us
> >>> to be consistent on how we name files in the repo.
> >>>
> >>> On Thu, Feb 11, 2016 at 1:40 PM, Kevin Klues 
> wrote:
> >>>
>  I prefer hyphens as well
> 
>  On Thu, Feb 11, 2016 at 1:28 PM, Jojy Varghese 
> >> wrote:
> > hyphen++. Is google friendly apparently.  Also less keys to press :)
> >
> > -Jojy
> >
> >
> >
> >> On Feb 11, 2016, at 12:43 PM, Greg Mann  wrote:
> >>
> >> +1
> >>
> >> On Thu, Feb 11, 2016 at 11:41 AM, Vinod Kone 
>  wrote:
> >>
> >>> Some the scripts in the "support" directory have dashes ("-") in
> >> their
> >>> names (e.g., apply-review.sh, apply-reviews.py), whereas some have
> >>> underscores ("_") (e.g., docker_build.sh, mesos_split.py).
> >>>
> >>> This is really confusing and we should stick with one style. I
> >> propose
>  to
> >>> change all them to use underscores. I will make sure the CI jobs
> are
> >>> updated accordingly.
> >>>
> >>> Any objections?
> >>>
> >>> Thanks,
> >>> Vinod
> >>>
> >
> 
> 
> 
>  --
>  ~Kevin
> 
> >>
> >>
> >>
> >> --
> >> ~Kevin
> >>
>
>


-- 
Best Regards,
Haosdent Huang

Re: Inconsistent naming of support scripts

[Alexander Rojas]

+1 for consistency, +1 for executables.

I do enough finger yoga while using emacs!

running `find /usr/local/bin -name "*-*" | wc -l` returned 142 while `find 
/usr/local/bin -name "*_*" | wc -l` was only 17. So I feel using hyphen for 
executables is more standard.

> On 11 Feb 2016, at 14:58, Michael Park  wrote:
> 
> +1 for consistency, +1 for hyphens for executables.
> 
> On 11 February 2016 at 14:25, Kevin Klues  wrote:
> 
>> I typically think of files having dashes as binaries or scripts that
>> are runnable, whereas files with underscores are meant as source or
>> otherwise supplementary to the binary produced (e.g. a supplementary
>> python library that the main python program imports).  I'm  not sure
>> where I inherited this convention from, but it's always been the way
>> I've done things.
>> 
>> As far as our code base goes, we seem to use this convention as well
>> with our mesos-master.sh. mesos-slave.sh, etc. binaries.
>> 
>> On Thu, Feb 11, 2016 at 2:17 PM, Vinod Kone  wrote:
>>> Why hyphens? Most of the files in our repo use underscores. I would like
>> us
>>> to be consistent on how we name files in the repo.
>>> 
>>> On Thu, Feb 11, 2016 at 1:40 PM, Kevin Klues  wrote:
>>> 
 I prefer hyphens as well
 
 On Thu, Feb 11, 2016 at 1:28 PM, Jojy Varghese 
>> wrote:
> hyphen++. Is google friendly apparently.  Also less keys to press :)
> 
> -Jojy
> 
> 
> 
>> On Feb 11, 2016, at 12:43 PM, Greg Mann  wrote:
>> 
>> +1
>> 
>> On Thu, Feb 11, 2016 at 11:41 AM, Vinod Kone 
 wrote:
>> 
>>> Some the scripts in the "support" directory have dashes ("-") in
>> their
>>> names (e.g., apply-review.sh, apply-reviews.py), whereas some have
>>> underscores ("_") (e.g., docker_build.sh, mesos_split.py).
>>> 
>>> This is really confusing and we should stick with one style. I
>> propose
 to
>>> change all them to use underscores. I will make sure the CI jobs are
>>> updated accordingly.
>>> 
>>> Any objections?
>>> 
>>> Thanks,
>>> Vinod
>>> 
> 
 
 
 
 --
 ~Kevin
 
>> 
>> 
>> 
>> --
>> ~Kevin
>> 

Re: Reorganize 3rdparty directory

[Alexander Rojas]

+1
I am one who is totally in for that change. It is not only the directories 
problem, but the structure which has led that the stout tests (which do need to 
be compiled) are actually managed in the libprocess Makefile, on top of all the 
things you have already mentioned.


> On 09 Feb 2016, at 17:53, Kapil Arya  wrote:
> 
> On Tue, Feb 9, 2016 at 8:23 PM, Jie Yu  wrote:
>> Kapil,
>> 
>> I guess what I want to understand is why the existing structure makes it
>> hard for you to do the things that you want to do (installing
>> module-specific 3rdparty dependencies into "${pkglibdir}/3rdparty" as part
>> of "make install").
> 
> Let me see if I can answer that :-).
> 
> This is somewhat related. For example, if we want to install protobuf
> in 3rdparty/{include,lib} (for module developers to use them without
> doing a proper mesos installation), you need to provide the correct
> "--prefix" flag that points to 3rdparty/. However, due to multiple
> levels of configure.ac, the "--prefix" can at best be generated by
> prepending "../../../" to get to the great-grandparent directory. This
> is because we have a separate configure.ac which manages
> 3rdparty/libprocess/3rdparty/Makefile.am. There are ways around it,
> but they are not clean.
> 
> Similar thing holds for system-wide installation of these 3rdparty
> packages. For example, ideally, we would want to use
> "${pkglibdir}/3rdparty" as a prefix for those packages. However, since
> they are part of libprocess package, we don't get the correct
> directory and have to use either hardwired $pkglibdir, or somehow pass
> it from the top-level configure all the way down to
> 3rdparty/libprocess/3rdparty/Makefile.am :-(.
> 
> 
>> The only reason you mentioned in the original email is that "in the current
>> code base, we don't strictly follow the 3rdparty structure", which IMO is
>> not a very convincing reason for such a big change.
> 
> How about a not so big change? :-). What if we just move
> 3rdparty/libprocess/3rdparty/* stuff out to 3rdparty/ while leaving
> stout as is? That is not a big change since we are not touching
> libprocess/stout. Just adjusting Makefiles and I am pretty sure it
> will be cleaner and simpler than what we have right now.
> 
> As a later time, we can then consider moving stout out to 3rdparty/
> while leaving libprocess as is. But that's something we can decide
> later and leave stout as an exception for now.
> 
> BTW, if we were to install all the 3rdparty packages in 3rdparty/,
> that would also cut down a lot on the compiler flags (i.e., fewer "-I"
> and "-L" flags) :-).
> 
> Kapil
> 
>> 
>> - Jie
>> 
>> On Tue, Feb 9, 2016 at 5:04 PM, Kapil Arya  wrote:
>> 
>>> On Tue, Feb 9, 2016 at 7:20 PM, Jie Yu  wrote:
 
> 
> However, in the current code base, we don't strictly follow the
>>> 3rdparty
> structure. For example, stout has a dependency on picojson and
> google-protobuf, but we don't put these two packages inside
> 3rdparty/libprocess/3rdparty/stout/3rdparty/.
 
 
 My understanding is that stout is header only. So it does not have to
 bundle 3rdparty libraries. The user of stout is responsible for bundling
 them if they are used.
>>> 
>>> 
>>> I don't think being header-only is an excuse to have a broken
>>> installation :-). Further, we don't make it easier for the user to get
>>> the 3rdparty binaries either. For example, if the user has a different
>>> version of protobuf installed on the system, the compilation of any
>>> program that uses stout will fail spectacularly!
>>> 
>>> Having said that, the gist here is that we have somewhat deviated from
>>> original motivation behind the 3rdparty directory and it would be nice
>>> if we can have a flatter structure.
>>> 
 
 
 - Jie
 
 On Tue, Feb 9, 2016 at 4:14 PM, Kapil Arya  wrote:
 
> Hi All,
> 
> TLDR: Move everything from 3rdparty/libprocess/3rdparty/* into
>>> 3rdparty/.
> (Optionally) Move libprocess/stout to the top-level directory.
> 
> I wanted to start some discussion around reorganizing stuff inside
> "3rdparty". I apologize for the length of the email, please bear with
>>> me.
> 
> Traditionally, 3rdparty has been used to hold all Mesos dependencies
> (zookeeper, libprocess, protobuf, stout, etc.). Further,
> libprocess/3rdparty was to hold all libprocess dependencies (which may
>>> in
> turn be Mesos dependencies as well).
> 
> As I understand, the original motivation was to emphasize that
>>> libprocess
> is an independent project which depends on "stout", which in turn is
>>> also
> an independent project.
> 
> However, in the current code base, we don't strictly follow the
>>> 3rdparty
> structure. For example, stout has a dependency on picojson and
> google-protobuf, but we don't put these two packages 

Re: Precision of scalar resources

[Alexander Rojas]

+1

Strong initial first step to remove a huge headache.

> On 12 Feb 2016, at 14:25, Neil Conway  wrote:
> 
> Additional precision in resource values will be discarded
> (via rounding).