Re: Mesos cluster across a wide area network

[Alexander Gallego]

On Fri, Dec 2, 2016 at 3:04 PM, Rodrick Brown 
wrote:

> How feasible is it to run Mesos across a private WAN.
>
> I have two data centers and private fiber between each location latency is
> about 80ms between both locations.
> My thinking is to run 5 masters Three in NY and 2 in London same setup for
> Zookeeper.
> I have about 120 nodes in NYC and 80 nodes in London.
>
> Or should I just create two silo clusters of 3 masters in each region.
>

If you do, you miss the opportunity of doing oversubscriptions. i.e.: say
NY is overloaded, you might want to move computations to London on a
pre-emptable schedule.

iff you can get zookeeper to be stable then you can do this.

if you only have 2 locations might not be a good idea as the leader
election is about consistency, so your cluster might not be able to launch
new work during a partition.


>
> Thanks.
>
> --
>
> RB
>
> *NOTICE TO RECIPIENTS*: This communication is confidential and intended
> for the use of the addressee only. If you are not an intended recipient of
> this communication, please delete it immediately and notify the sender by
> return email. Unauthorized reading, dissemination, distribution or copying
> of this communication is prohibited. This communication does not constitute
> an offer to sell or a solicitation of an indication of interest to purchase
> any loan, security or any other financial product or instrument, nor is it
> an offer to sell or a solicitation of an indication of interest to purchase
> any products or services to any persons who are prohibited from receiving
> such information under applicable law. The contents of this communication
> may not be accurate or complete and are subject to change without notice.
> As such, Orchard App, Inc. (including its subsidiaries and affiliates,
> "Orchard") makes no representation regarding the accuracy or completeness
> of the information contained herein. The intended recipient is advised to
> consult its own professional advisors, including those specializing in
> legal, tax and accounting matters. Orchard does not provide legal, tax or
> accounting advice.
>



-- 





Alexander Gallego
Co-Founder & CTO

Authentication module

[Alexander Gallego]

For the authentication module:
http://mesos.apache.org/documentation/latest/modules/ does it mean
kerberos,ldap, etc for tasks or for framework registration or for machine
registration

are there any more docs on this?

Re: Initial Design Document Apache Mesos Federation (JIRA 3548)

[Alexander Gallego]

On Thu, Jul 14, 2016 at 2:40 AM, DhilipKumar Sankaranarayanan <
s.dhilipku...@gmail.com> wrote:

> HI Alex,
>
> Thanks for taking a look.  We have simplified the design since the
> conference.  The Allocation and Anonymous modules where only helping us to
> control the offers sent to the frameworks.  Now we think that Roles and
> Quota in Moses elegantly solve this problem and we could take advantage of
> it.
>

Sounds good, given that the design is entirely different now, can you share
some of these thoughts.


>
> The current design does not propose Mesos Modules, the POC we demonstrated
> @ the mesoscon is slightly out of date in that respect.
>
> The current design only enforces that any Policy Engine implementation
> should honour certain REST apis.   This also removes Consul out of the
> picture, but at Huawei our implementation would pretty much consider Consul
> or something similar.
>
> 1) Failure semantics
> I do agree it is not straight forward to declare that a DC is lost just
> because framework lost the connection intermittently.  Probing the
> 'Gossiper' we would know that the DC is still active but not just reachable
> to us,  In that case its worth the wait.  If the DC in question is not
> reachable from everyother DC, only then we could come to such conclusion.
>
>

how do you envision frameworks integrating w/ this. Are you saying that
frameworks should poll the HTTP endpoint of the Gossiper?



> 2)  Can you share more details about the allocator modules.
> As mentioned earlier these modules are no longer relevant we have much
> simpler way to achieve this.
>
> 3) High Availability
> I think you are talking about the below section?
> "Sequence Diagram for High Availability
>
> (Incase of local datacenter failure)
> Very Similar to cloud bursting use-case scenario.  "
> The sequence diagram only represents flow of events in case if the current
> datacenter fails and the framework needs to connect to a new one.  It is
> not talking about the approach you mentioned.  I will update doc couple
> more diagrams soon to make it more understandable.  We would certainly like
> to have a federated K/V storage layer across the DCs which is why Consul
> was considered in the first place.
>
>
Does this mean that you have to run the actual framework code in all of the
DC's ?  or you have yet to iron this out?




> 4) Metrics / Monitoring - probably down the line
> The experimental version of gossiper already queries the maser at a
> frequent interval and exchange it amongst them.
>
> Ultimately DC federation is a hard problem to solve.  We have plenty of
> use cases which is why we wanted to reach out to the community, share our
> experience and build something that is useful for all of us.
>
>
Thanks !! excited about this work.


> Regards,
> Dhilip
>
>
> On Wed, Jul 13, 2016 at 7:58 PM, Alexander Gallego 
> wrote:
>
>> This is very cool work, i had a chat w/ another company thinking about
>> doing the exact same thing.
>>
>> I think the proposal is missing several details that make it hard to
>> evaluate on paper (also saw your presentation).
>>
>>
>> 1) Failure semantics, seem to be the same from the proposed design.
>>
>>
>> As a framework author, how do you suggest you deal w/ tasks on multiple
>> clusters, i.e.: i feel like there have to be richer semantics about the
>> task at least on the mesos.proto level where the state is
>> STATUS_FAILED_DC_OUTAGE or smth along those lines.
>>
>> We respawn operators and having this information may allow me as a
>> framework author to wait a little longer before trying to declare that task
>> as dead (KILLED/FAILED/LOST) if I spawn it on a different data center.
>>
>> Would love to get details on how you were thinking of extending the
>> failure semantics for multi datacenters.
>>
>>
>> 2) Can you share more details about the allocator modules.
>>
>>
>> After reading the proposal, I anderstand it as follows.
>>
>>
>> [ gossiper ] -> [ allocator module ] -> [mesos master]
>>
>>
>> Is this correct ? if so, you are saying that you can tell the mesos
>> master to run a task  that was fulfilled by a framework on a different data
>> center?
>>
>> Is the constraint that you are forced to run a scheduler per framework on
>> each data center?
>>
>>
>>
>> 3) High availability
>>
>>
>> High availability on a multi dc layout means something entirely
>> different. So are all frameworks now on standby on every other cluster? the
>> problem i see with this is that the metadata stor

Re: Initial Design Document Apache Mesos Federation (JIRA 3548)

[Alexander Gallego]

This is very cool work, i had a chat w/ another company thinking about
doing the exact same thing.

I think the proposal is missing several details that make it hard to
evaluate on paper (also saw your presentation).


1) Failure semantics, seem to be the same from the proposed design.


As a framework author, how do you suggest you deal w/ tasks on multiple
clusters, i.e.: i feel like there have to be richer semantics about the
task at least on the mesos.proto level where the state is
STATUS_FAILED_DC_OUTAGE or smth along those lines.

We respawn operators and having this information may allow me as a
framework author to wait a little longer before trying to declare that task
as dead (KILLED/FAILED/LOST) if I spawn it on a different data center.

Would love to get details on how you were thinking of extending the failure
semantics for multi datacenters.


2) Can you share more details about the allocator modules.


After reading the proposal, I anderstand it as follows.


[ gossiper ] -> [ allocator module ] -> [mesos master]


Is this correct ? if so, you are saying that you can tell the mesos master
to run a task  that was fulfilled by a framework on a different data
center?

Is the constraint that you are forced to run a scheduler per framework on
each data center?



3) High availability


High availability on a multi dc layout means something entirely different.
So are all frameworks now on standby on every other cluster? the problem i
see with this is that the metadata stored by each framework to support HA
now has to spans multiple DC's. It would be nice to perhaps at the mesos
level extend/expose an API for setting state.

a) On the normal mesos layout, this key=value data store would be
zookeeper.

b) On the multi dc layout it could be zookeeper per data center but then
one can piggy back on the gossiper to replicate that state in the other
data centers.


4) Metrics / Monitoring - probably down the line, but would be good to also
piggy back some of the mesos master endpoints
through the gossip architecture.



Again very cool work, would love to get some more details on the actual
implementation that you built plus some of the points above.

- Alex







On Wed, Jul 13, 2016 at 6:11 PM, DhilipKumar Sankaranarayanan <
s.dhilipku...@gmail.com> wrote:

> Hi All,
>
> Please find the initial version of the Design Document
> <https://docs.google.com/document/d/1U4IY_ObAXUPhtTa-0Rw_5zQxHDRnJFe5uFNOQ0VUcLg/edit?usp=sharing>
> for Federating Mesos Clusters.
>
>
> https://docs.google.com/document/d/1U4IY_ObAXUPhtTa-0Rw_5zQxHDRnJFe5uFNOQ0VUcLg/edit?usp=sharing
>
> We at Huawei had been working on this federation project for the past few
> months.  We also got an opportunity to present this in recent MesosCon
> 2016. From further discussions and feedback we have received so far, we
> have greatly simplified the design.
>
> Also I see that no one assigned to this JIRA now could i get that assigned
> to myself ? It would be great to know if there is anyone willing to
> shepherd this too.
>
> I would also like to bring this up in the community Sync that happens
> tomorrow.
>
> We would love to hear your thoughts. We will be glad to see collaborate
> with you in the implementation.
>
> Regards,
> Dhilip
>
>
> Reference:
> JIRA: https://issues.apache.org/jira/browse/MESOS-3548
> Slides:
> http://www.slideshare.net/mKrishnaKumar1/federated-mesos-clusters-for-global-data-center-designs
> Video :
> https://www.youtube.com/watch?v=kqyVQzwwD5E&index=17&list=PLGeM09tlguZQVL7ZsfNMffX9h1rGNVqnC
>
>


-- 





Alexander Gallego
Co-Founder & CTO

How to get the web_ui to use --advertise_ip from the slaves

[Alexander Gallego]

Hello,


I'm trying to get the web_ui to use the --advertise_ip to connect to
master's instead of the --hostname passed into the slaves.

running mesos 28

slaves run with a command like this:

mesos-slave --master=zk://xxx/mesos --advertise_ip=y.y.y.y
--containerizers=docker,mesos --hostname=tmp-mesos-slave-1 --ip=10.240.0.6

So when you hit sandbox, it connects to the --hostname.


Background:

I had been using ip (public) for --hostname which worked well for my
framework, but when launching spark on mesos, it requires the internal ip
for it to work on GCE.

Thanks!

Re: ERROR while installing mesos

[Alexander Gallego]

Did you add any ./configure flags?

On Thu, Oct 29, 2015 at 3:04 AM, Sharma, Showvik 
wrote:

> Hi,
>
>
>
> While installing mesos, first I configured mesos-0.25.0. Everything was
> perfectly fine.
>
> But  while doing make I am getting below error.
>
>
>
>
>
> /bin/sh ../libtool  --tag=3DCXX   --mode=3Dlink g++ -pthread -g1 -O0
> -Wno-unused-local-typedefs -std=3Dc++11 -Wl,--as-needed  -o mesos-local
> local/mesos_local-main.o libmesos.la -lsasl2 -lsvn_delta-1
> -lsvn_subr-1 -lapr-1 -lcurl -lz  -lrt
>
> libtool: link: g++ -pthread -g1 -O0 -Wno-unused-local-typedefs
> -std=3Dc++11=  -Wl,--as-needed -o .libs/mesos-local
> local/mesos_local-main.o  ./.libs/lib= mesos.so -lsasl2
> /usr/lib64/libsvn_delta-1.so /usr/lib64/libsvn_subr-1.so /=
> usr/lib64/libaprutil-1.so -lcrypt -lexpat -ldb-5.3 /usr/lib64/libapr-1.so
> -= lpthread -ldl -lcurl -lz -lrt -pthread -Wl,-rpath -Wl,/usr/local/lib
> -Wl,-r= path -Wl,/usr/lib64
>
> ./.libs/libmesos.so: undefined reference to `svn_txdelta2'
>
> collect2: error: ld returned 1 exit status
>
> make[2]: *** [mesos-local] Error 1
>
> make[2]: Leaving directory `/home/mesos-0.25.0/build/src'
>
> make[1]: *** [all] Error 2
>
> make[1]: Leaving directory `/home/mesos-0.25.0/build/src'
>
> make: *** [all-recursive] Error 1
>
>
>
> Can you please tell me what to do so that I can resolve this issue.
>
>
>
>
>
> Thanks
>
> Showvik
>
>
>



--

Re: Building portable binaries

[Alexander Gallego]

My build system is a HUGE PITA.

Right now it is a set of 77 ansible roles. For configuring. half of them
are for mesos.

The reason to have ansible do it exactly because of what you are seeing,
but it gets more complex for framework authors (combination of operating
systems types, versions, libraries, system installed libs, etc)

We build all the transitive dependencies from source too (as many as we can)

So, the flags are exactly what you're using and adding
--with-glog=/usr/local/lib

We just  ` make `  and the ansible scripts move things to the right
directories.

Basically we found that trying to give all of the transitive dependencies a
custom installation path and custom LD_LIBRARY_PATH was hard and it kept
breaking.

So, the way we build it is:

1. Only run make for all deps (never make install - though, some libs
actually perform an install with make, just FYI)
2. Manually link or move the libraries to /usr/local/lib
3. fix your ldconfig


Packaging contents for my deployments is simpler as I deploy only on docker
images. Effectively:


```

 curl -L https:.. | tar -xzf -

```

And it's not an issue because we've placed things in the default
directories.

- alex









On Thu, Sep 17, 2015 at 8:16 PM, F21  wrote:

> Thanks for your pointers! I will give that a try to see if I can track
> down the problem.
>
> Do you mind sharing a bit more about your build process?
>
> What do your ./configure flags look like? Also, do you do a `make install`
> and then package up the contents?
>
> Cheers!
>
>
> On 18/09/2015 10:06 AM, Alexander Gallego wrote:
>
> I run a custom build of mesos and it works pretty reliably, so I'll try to
> share what I do in the hopes that it helps you.
>
> The symptom you are seeing of exiting before anything is output to the
> logs has been usually an issue with the LD_LIBRARY_PATH being screwed up. I
> would try to ssh into the machines and run the command manually.
>
> Native code is a bit hard to debug, but this is what I do for a cluster to
> figure out mesos issues.
>
> 1. Recompile with -ggdb and ship dwarf symbols (if you don't want to,
> you'll have to symbolize the binary later)
> 2. echo 'core.%h.%e.%t' > /proc/sys/kernel/core_pattern on all your
> machines
> 3. wrap your mesos executors (if native) as well as mesos-master and
> mesos-slave in a bash script that you control
> 4. In this bash script, set the filehandle limits from the soft to the hard
> 5. In this bash script, set the core dump limits to unlimited
>
> When it crashes, it will be pretty straight forward to debug with the core
> dump, it will almost tell you the exact assembly instruction, or exception
> in the code.
>
> I've never had crashes with mesos after compiling with
>
> ```
> -mtune=generic
> ```
>
> I had something similar to my rocksdb build (
> <https://github.com/facebook/rocksdb/issues/690>
> https://github.com/facebook/rocksdb/issues/690) happened to my mesos
> build when I was first starting and compiling with -mtune=native
>
> If you are linking the libmesos.so into another process (i.e.: you wrote
> your own native executor) then make sure you do something similar to the
> core dump limits.
>
> Note: If you are running dockerized/containerized deployments you won't be
> able to modify the /proc/sys/* , so this will have to be done on the host
> computers.
>
> I've been meaning to write a blog post about this, but this is the TL;DR.
>
> Hope this helps.
>
> - Alex
>
>
>
>
>
>
>
> On Thu, Sep 17, 2015 at 7:33 PM, F21  wrote:
>
>> Is there anyway to build portable binaries for mesos?
>>
>> Currently, I have tried building my own libsvn, libsasl2, libcurl, libapr
>> and then built mesos using the following:
>>
>> ../configure CC=gcc-4.8 CXX=g++-4.8
>> LD_LIBRARY_PATH=/tmp/mesos-build/sasl2/lib
>> SASL_PATH=/tmp/mesos-build/sasl2/lib/sasl2 --prefix=/tmp/mesos-build/mesos
>> --with-svn=/tmp/mesos-build/svn --with-apr=/tmp/mesos-build/apr
>> --with-sasl=/tmp/mesos-build/sasl2/ --with-curl=/tmp/mesos-build/curl
>> make
>> make install
>>
>> I then compress /tmp/mesos-build/mesos into an archive and distribute it
>> to my machines. The only problem is that the build seems to be buggy. For
>> example, I've been experiencing a containerization issues where the
>> executors will crash, but not output anything useful to stderr and stdout.
>> See <https://github.com/mesosphere/hdfs/issues/194>
>> https://github.com/mesosphere/hdfs/issues/194
>>
>> Is there a definite way to build portable binaries that I can easily copy
>> to another machine to run?
>>
>
>
>
> --
>
>
>
>
>
> Alexander Gallego |   <http://concord.io>http://concord.io
>
>
>


-- 





Alexander Gallego |  http://concord.io

Re: Building portable binaries

[Alexander Gallego]

I run a custom build of mesos and it works pretty reliably, so I'll try to
share what I do in the hopes that it helps you.

The symptom you are seeing of exiting before anything is output to the logs
has been usually an issue with the LD_LIBRARY_PATH being screwed up. I
would try to ssh into the machines and run the command manually.

Native code is a bit hard to debug, but this is what I do for a cluster to
figure out mesos issues.

1. Recompile with -ggdb and ship dwarf symbols (if you don't want to,
you'll have to symbolize the binary later)
2. echo 'core.%h.%e.%t' > /proc/sys/kernel/core_pattern on all your machines
3. wrap your mesos executors (if native) as well as mesos-master and
mesos-slave in a bash script that you control
4. In this bash script, set the filehandle limits from the soft to the hard
5. In this bash script, set the core dump limits to unlimited

When it crashes, it will be pretty straight forward to debug with the core
dump, it will almost tell you the exact assembly instruction, or exception
in the code.

I've never had crashes with mesos after compiling with

```
-mtune=generic
```

I had something similar to my rocksdb build (
https://github.com/facebook/rocksdb/issues/690) happened to my mesos build
when I was first starting and compiling with -mtune=native

If you are linking the libmesos.so into another process (i.e.: you wrote
your own native executor) then make sure you do something similar to the
core dump limits.

Note: If you are running dockerized/containerized deployments you won't be
able to modify the /proc/sys/* , so this will have to be done on the host
computers.

I've been meaning to write a blog post about this, but this is the TL;DR.

Hope this helps.

- Alex







On Thu, Sep 17, 2015 at 7:33 PM, F21  wrote:

> Is there anyway to build portable binaries for mesos?
>
> Currently, I have tried building my own libsvn, libsasl2, libcurl, libapr
> and then built mesos using the following:
>
> ../configure CC=gcc-4.8 CXX=g++-4.8
> LD_LIBRARY_PATH=/tmp/mesos-build/sasl2/lib
> SASL_PATH=/tmp/mesos-build/sasl2/lib/sasl2 --prefix=/tmp/mesos-build/mesos
> --with-svn=/tmp/mesos-build/svn --with-apr=/tmp/mesos-build/apr
> --with-sasl=/tmp/mesos-build/sasl2/ --with-curl=/tmp/mesos-build/curl
> make
> make install
>
> I then compress /tmp/mesos-build/mesos into an archive and distribute it
> to my machines. The only problem is that the build seems to be buggy. For
> example, I've been experiencing a containerization issues where the
> executors will crash, but not output anything useful to stderr and stdout.
> See https://github.com/mesosphere/hdfs/issues/194
>
> Is there a definite way to build portable binaries that I can easily copy
> to another machine to run?
>



-- 





Alexander Gallego |  http://concord.io

Re: Build mesos failed when trying to dynamically linked against libgflags and libglog.

[Alexander Gallego]

This  is my configure step inside my ansible script for building mesos:

- name: configure mesos
  shell: "LIBS=-lglog LDFLAGS=-L/usr/local/lib
/{{mesos_dir}}/configure
--with-glog=/usr/local"


Basically when you configure it, pass it the --with-* flags.




On Wed, Sep 9, 2015 at 9:07 AM, sujz <43183...@qq.com> wrote:

> Hi all:
> I am trying to run mesos on host which already installed libgflags and
> libglog, so I hope libmesos.so can dynamically loads libgflags and libglog.
>
> If I built mesos with configure && make && make install commands with no
> additional options, and copy released package on destination host, I found
> that it complains depends on libgflags.2 but not depends on libglog.2, so I
> guess libglog is statically linked into libmesos.so, after specifying the
> pre-installed libgflags path and run mesos-master, it produced an ERROR:
> something wrong with flag 'logtostderr' in file 'src/logging.cc'. One
> possibility: file 'src/logging.cc' is being linked both statically and
> dynamically into this executable.
>
> I also tried configure with LIBS='-lglog' --enable-shared=yes
> --enable-static=no or LIBS='-lgflags -lglog' --enable-shared=yes
> --enable-static=no, this time it complains depending on both libgflags and
> libglog, but with no luck, the same error produced.
>
> So could somebody be kind to tell me how to build mesos that can
> dynamically linked against libgflags and libglog that already installed on
> destination host?  thank you very much!




--

Re: MesosCon Seattle attendee introduction thread

[Alexander Gallego]

Hi,

I'm Alex, I'm working on a distributed stream processor in c++ (concord.io).
Looking forward to connecting with all of you. Would be great to meet with
people doing large cluster load testing on mesos :)

I'll be at the hackathon with some coworkers as well.



On Mon, Aug 17, 2015 at 1:48 PM, Nic Grayson  wrote:

> Hi,
>
> I'm Nic Grayson, Software Engineer at Banno/Jack Henry & Associates. I'm
> excited to return to mesoscon this year. I'll be bringing more of our team
> with me this year, 7 in total.
>
> We've been hard at work automating deployments with terraform, marathon,
> and mesos. I’m excited to see the progress all of the major frameworks have
> made over the last year. We are now using terraform to interact with the
> kafka framework api (http://nicgrayson.com/mesos-kafka-terraform/)
>
> Nic
>
> On Mon, Aug 17, 2015 at 12:20 PM, Sharma Podila 
> wrote:
>
>> Hello Everyone,
>>
>> I am Sharma Podila, senior software engineer at Netflix. It is exciting
>> to be a part of MesosCon again this year.
>> We developed a cloud native Mesos framework to run a mix of service,
>> batch, and stream processing workloads. To which end we created a reusable
>> plug-ins based scheduling library, Fenzo. I am looking forward to
>> presenting an in-depth look on Thurs at 2pm about how we achieve scheduling
>> objectives and cluster autoscaling, as well as share some of our results
>> with you.
>>
>> I am interested in learning about and collaborating with you all
>> regarding scheduling and framework development.
>>
>> Sharma
>>
>>
>>
>> On Mon, Aug 17, 2015 at 2:11 AM, Ankur Chauhan 
>> wrote:
>>
>>> Hi all,
>>>
>>> I am Ankur Chauhan. I am a Sr. Software engineer with the Reporting and
>>> Analytics team
>>> at Brightcove Inc. I have been evaluating, tinkering, developing with
>>> mesos for about an year
>>> now. My latest adventure has been in the spark mesos integration and
>>> writing the new apache flink -
>>> mesos integration.
>>>
>>> I am interested in learning about managing stateful services in mesos
>>> and creating better documentation
>>> for the project.
>>>
>>> I am very excited to meet everyone!
>>>
>>> -- Ankur Chauhan.
>>>
>>> > On 17 Aug 2015, at 00:10, Trevor Powell  wrote:
>>> >
>>> > Hey Mesos Family! Can¹t wait to see you all in person.
>>> >
>>> > I¹m Trevor Powell. I am the Product Owner for our TechOps engineering
>>> team
>>> > at RMS. RMS is in the catastrophic modeling business. Think of it as
>>> > modeling Acts of God (earthquakes, floods, Godzilla, etc)  on physical
>>> > property and damages associated with them.
>>> >
>>> > We¹ve been evaluating Mesos this year, and we are planning to launch
>>> it in
>>> > PRD at the start of next. I am super excited :-)
>>> >
>>> > I am very interested in managing stateful applications inside Mesos.
>>> Also
>>> > network segmentation in Mesos (see my ³Mesos, Multinode Workload
>>> Network
>>> > segregation² email thread earlier this month).
>>> >
>>> > See you all Thursday!!
>>> >
>>> > Stay Smooth,
>>> >
>>> > --
>>> >
>>> > Trevor Alexander Powell
>>> > Sr. Manager, Cloud Engineer & Architecture
>>> > 7575 Gateway Blvd. Newark, CA 94560
>>> > T: +1.510.713.3751
>>> > M: +1.650.325.7467
>>> > www.rms.com
>>> > https://www.linkedin.com/in/trevorapowell
>>> >
>>> > https://github.com/tpowell-rms
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On 8/16/15, 1:58 PM, "Dave Lester"  wrote:
>>> >
>>> >> Hi All,
>>> >>
>>> >> I'd like to kick off a thread for folks to introduce themselves in
>>> >> advance of #MesosCon
>>> >> . Here goes:
>>> >>
>>> >> My name is Dave Lester, and I'm an Open Source Advocate at Twitter. I
>>> am
>>> >> a member of the MesosCon program committee, along with a stellar group
>>> >> of other community members who have volunteered
>>> >> <
>>> http://events.linuxfoundation.org/events/mesoscon/program/programcommitte
>>> >> e>.
>>> >> Can't wait to meet as many of you as possible.
>>> >>
>>> >> I'm eager to meet with folks interested in learning more about how we
>>> >> deploy and manage services at Twitter using Mesos and Apache Aurora
>>> >> . Twitter has a booth where I'll be hanging
>>> >> out for a portion of the conference, feel free to stop by and say hi.
>>> >> I'm also interested in connecting with companies that use Mesos; let's
>>> >> make sure we add you to our #PoweredByMesos list
>>> >> .
>>> >>
>>> >> I'm also on Twitter: @davelester
>>> >>
>>> >> Next!
>>> >
>>>
>>>
>>
>

Proposing a fatal log for not finding mesos-fetcher

[Alexander Gallego]

I was debugging a mesos installation and came across this in the
mesos-master.error log

E0730 22:09:32.288753   178 containerizer.cpp:556] Failed to determine
the canonical path for the mesos-fetcher
'/usr/local/libexec/mesos/mesos-fetcher': No such file or directory


The issue is that when you try to then launch a task you get a (w/ c++-filt)

$ c++filt 
_ZNSt5_BindIFPFiRKSsPPcRKN7process10Subprocess2IOES8_S8_PN2os7ExecEnvERK6OptionISt8functionIFivEEEPiSJ_SJ_ESsS3_S6_S6_S6_SB_SG_SJ_SJ_SJ_EE6__callIiJEJLm0ELm1ELm2ELm3ELm4ELm5ELm6ELm7ELm8ELm9T_OSt5tupleIJDpT0_EESt12_Index_tupleIJXspT1_EEE
int std::_Bind,
std::allocator >, char**, process::Subprocess::IO,
process::Subprocess::IO, process::Subprocess::IO, os::ExecEnv*,
Option >, int*, int*,
int*))(std::basic_string,
std::allocator > const&, char**, process::Subprocess::IO const&,
process::Subprocess::IO const&, process::Subprocess::IO const&,
os::ExecEnv*, Option > const&, int*, int*,
int*)>::__call(std::tuple<>&&, std::_Index_tuple<0ul, 1ul, 2ul, 3ul, 4ul, 5ul,
6ul, 7ul, 8ul, 9ul>)



which is basically impossible to realize that the error is here:

https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/subprocess.cpp#L177

and that the source is that the fetcher is missing.

Eventually i diff'ed a working copy of a filesystem and found that
/usr/local/libexec/mesos was missing.


Technically this isn't an error w/ mesos as in if the executables are in
place, things will run smoothly. However, if part of mesos is not in the
environment, then is the consensus to just 'attempt' to work instead of
failing fast. i.e.: failing on startup with a log that says?

mesos-fetcher missing, please check /usr/local/libexec/mesos (default)

Just a thought.

Re: High latency when scheduling and executing many tiny tasks.

[Alexander Gallego]

I take back the executor in scala. Just looked at the source and both
PathExecutor and CommandExecutor proxy to mesos TaskBuilder.setCommand


executor match {
  case CommandExecutor() =>
builder.setCommand(TaskBuilder.commandInfo(app, Some(taskId), host,
ports, envPrefix))
containerProto.foreach(builder.setContainer)

  case PathExecutor(path) =>
val executorId = f"marathon-${taskId.getValue}" // Fresh executor
val executorPath = s"'$path'" // TODO: Really escape this.
val cmd = app.cmd orElse app.args.map(_ mkString " ") getOrElse ""
val shell = s"chmod ug+rx $executorPath && exec $executorPath $cmd"
val command = TaskBuilder.commandInfo(app, Some(taskId), host,
ports, envPrefix).toBuilder.setValue(shell)

val info = ExecutorInfo.newBuilder()
  .setExecutorId(ExecutorID.newBuilder().setValue(executorId))
  .setCommand(command)
containerProto.foreach(info.setContainer)
builder.setExecutor(info)
val binary = new ByteArrayOutputStream()
mapper.writeValue(binary, app)
builder.setData(ByteString.copyFrom(binary.toByteArray))
}


The pattern of execvp'ing is still what I use and in fact what mesos uses:

if (task.command().shell()) {
  execl(
  "/bin/sh",
  "sh",
  "-c",
  task.command().value().c_str(),
  (char*) NULL);
} else {
  execvp(task.command().value().c_str(), argv);
}


Sorry for the missinformation about the executor in Marathon.



On Fri, Jul 17, 2015 at 5:20 PM, Philip Weaver 
wrote:

> Ok, thanks!
>
> On Fri, Jul 17, 2015 at 2:18 PM, Alexander Gallego 
> wrote:
>
>> I use a similar pattern.
>>
>> I have my own scheduler as you have. I deploy my own executor which
>> downloads a tar from some storage and effectively ` execvp ( ... ) ` a
>> proc. It monitors the child proc and reports status of child pid exit
>> status.
>>
>> Check out the Marathon code if you are writing in scala. It is an
>> excellent example for both scheduler and executor templates.
>>
>> -ag
>>
>> On Fri, Jul 17, 2015 at 5:06 PM, Philip Weaver 
>> wrote:
>>
>>> Awesome, I suspected that was the case, but hadn't discovered the
>>> --allocation_interval flag, so I will use that.
>>>
>>> I installed from the mesosphere RPMs and didn't change any flags from
>>> there. I will try to find some logs that provide some insight into the
>>> execution times.
>>>
>>> I am using a command task. I haven't looked into executors yet; I had a
>>> hard time finding some examples in my language (Scala).
>>>
>>> On Fri, Jul 17, 2015 at 2:00 PM, Benjamin Mahler <
>>> benjamin.mah...@gmail.com> wrote:
>>>
>>>> One other thing, do you use an executor to run many tasks? Or are you
>>>> using a command task?
>>>>
>>>> On Fri, Jul 17, 2015 at 1:54 PM, Benjamin Mahler <
>>>> benjamin.mah...@gmail.com> wrote:
>>>>
>>>>> Currently, recovered resources are not immediately re-offered as you
>>>>> noticed, and the default allocation interval is 1 second. I'd recommend
>>>>> lowering that (e.g. --allocation_interval=50ms), that should improve the
>>>>> second bullet you listed. Although, in your case it would be better to
>>>>> immediately re-offer recovered resources (feel free to file a ticket for
>>>>> supporting that).
>>>>>
>>>>> For the first bullet, mind providing some more information? E.g.
>>>>> master flags, slave flags, scheduler logs, master logs, slave logs,
>>>>> executor logs? We would need to trace through a task launch to see where
>>>>> the latency is being introduced.
>>>>>
>>>>> On Fri, Jul 17, 2015 at 12:26 PM, Philip Weaver <
>>>>> philip.wea...@gmail.com> wrote:
>>>>>
>>>>>> I'm trying to understand the behavior of mesos, and if what I am
>>>>>> observing is typical or if I'm doing something wrong, and what options I
>>>>>> have for improving the performance of how offers are made and how tasks 
>>>>>> are
>>>>>> executed for my particular use case.
>>>>>>
>>>>>> I have written a Scheduler that has a queue of very small tasks (for
>>>>>> testing, they are "echo hello world", but in pr

Re: High latency when scheduling and executing many tiny tasks.

[Alexander Gallego]

I use a similar pattern.

I have my own scheduler as you have. I deploy my own executor which
downloads a tar from some storage and effectively ` execvp ( ... ) ` a
proc. It monitors the child proc and reports status of child pid exit
status.

Check out the Marathon code if you are writing in scala. It is an excellent
example for both scheduler and executor templates.

-ag

On Fri, Jul 17, 2015 at 5:06 PM, Philip Weaver 
wrote:

> Awesome, I suspected that was the case, but hadn't discovered the
> --allocation_interval flag, so I will use that.
>
> I installed from the mesosphere RPMs and didn't change any flags from
> there. I will try to find some logs that provide some insight into the
> execution times.
>
> I am using a command task. I haven't looked into executors yet; I had a
> hard time finding some examples in my language (Scala).
>
> On Fri, Jul 17, 2015 at 2:00 PM, Benjamin Mahler <
> benjamin.mah...@gmail.com> wrote:
>
>> One other thing, do you use an executor to run many tasks? Or are you
>> using a command task?
>>
>> On Fri, Jul 17, 2015 at 1:54 PM, Benjamin Mahler <
>> benjamin.mah...@gmail.com> wrote:
>>
>>> Currently, recovered resources are not immediately re-offered as you
>>> noticed, and the default allocation interval is 1 second. I'd recommend
>>> lowering that (e.g. --allocation_interval=50ms), that should improve the
>>> second bullet you listed. Although, in your case it would be better to
>>> immediately re-offer recovered resources (feel free to file a ticket for
>>> supporting that).
>>>
>>> For the first bullet, mind providing some more information? E.g. master
>>> flags, slave flags, scheduler logs, master logs, slave logs, executor logs?
>>> We would need to trace through a task launch to see where the latency is
>>> being introduced.
>>>
>>> On Fri, Jul 17, 2015 at 12:26 PM, Philip Weaver >> > wrote:
>>>
 I'm trying to understand the behavior of mesos, and if what I am
 observing is typical or if I'm doing something wrong, and what options I
 have for improving the performance of how offers are made and how tasks are
 executed for my particular use case.

 I have written a Scheduler that has a queue of very small tasks (for
 testing, they are "echo hello world", but in production many of them won't
 be much more expensive than that). Each task is configured to use 1 cpu
 resource. When resourceOffers is called, I launch as many tasks as I can in
 the given offers; that is, one call to driver.launchTasks for each offer,
 with a list of tasks that has one task for each cpu in that offer.

 On a cluster of 3 nodes and 4 cores each (12 total cores), it takes
 120s to execute 1000 tasks out of the queue. We are evaluting mesos because
 we want to use it to replace our current homegrown cluster controller,
 which can execute 1000 tasks in way less than 120s.

 I am seeing two things that concern me:

- The time between driver.launchTasks and receiving a callback to
statusUpdate when the task completes is typically 200-500ms, and 
 sometimes
even as high as 1000-2000ms.
- The time between when a task completes and when I get an offer
for the newly freed resource is another 500ms or so.

 These latencies explain why I can only execute tasks at a rate of about
 8/s.

 It looks like my offers always include all 4 cores on each machine,
 which would indicate that mesos doesn't like to send an offer as soon as a
 single resource is avaiable, and prefers to delay and send an offer with
 more resources in it. Is this true?

 Thanks in advance for any advice you can offer!

 - Phllip


>>>
>>
>

Re: Setting Rate of Resource Offers

[Alexander Gallego]

Chris,


```
 driver_->requestResources(pendingResources);
```

The design is there, but as far as I'm concerned this is a noop. You can
try and track that and maybe implement a patch in the scheduler.





On Wed, Jun 17, 2015 at 1:18 PM, Vinod Kone  wrote:

> Can you paste the master logs for when the task is finished and the next
> offer is sent?
>
> On Wed, Jun 17, 2015 at 9:11 AM, Christopher Ketchum 
> wrote:
>
>> Hi everyone,
>>
>> Thanks for the responses. To clarify, I’m only running one framework with
>> a single slave for testing purposes, and it is the re-offers that I am
>> trying to adjust. When I watch the program run I see tasks updating to
>> TASK_FINISHED, but there is a noticeable delay where my framework has the
>> next task queued but the master has not yet reoffered those resources, so
>> the program pauses until it gets the next offer.
>>
>> I am mainly concerned that I haven’t configured something properly, and
>> when I scale up the delays will compound. Of course, it is also possible
>> that with multiple slaves able to offer resources these delays will
>> disappear.
>>
>> Thanks again,
>> Christopher
>>
>> On Jun 14, 2015, at 8:11 AM, Alex Gaudio  wrote:
>>
>> Hi Christopher,
>>
>> To let a particular mesos framework receive more offers than other
>> frameworks, we assign our frameworks weights.  The higher the weight, the
>> more frequently the framework will receive an offer.  See the '--weights'
>> and '--roles' options in the config:
>> http://mesos.apache.org/documentation/latest/configuration/.  Basically,
>> a higher weight > 1 means more offers get sent to your framework.  The
>> mesos source code for how weighting works is shown here:
>> https://github.com/apache/mesos/blob/9e7b890a917fcf0ac4cd1738f060ba97af847b65/src/master/allocator/sorter/drf/sorter.cpp#L306
>> and
>> https://github.com/apache/mesos/blob/9e7b890a917fcf0ac4cd1738f060ba97af847b65/src/master/allocator/sorter/drf/sorter.cpp#L41
>> .
>>
>> What you may want to do is create a "role" called "development_mode" and
>> then assign the role a high weight (like 40).  You would then assign your
>> framework to the "development_mode" role.  What we've actually done is
>> created roles named the numbers 1,2,3,4,5,10,20,30,40, where each role maps
>> to a weight of that number ... and we then we allow frameworks to choose
>> which role they start up as.  At Mesoscon, I will be speaking about why we
>> do this and how we are solving some general issues with the DRF algorithm,
>> if you're interested!
>>
>> Alex
>>
>>
>>
>> On Sun, Jun 14, 2015 at 5:58 AM Alex Rukletsov 
>> wrote:
>>
>>> Christopher,
>>>
>>> try adjusting master allocation_interval flag. It specifies often the
>>> allocator performs batch allocations to frameworks. As Ondrej pointed out,
>>> if you framework explicitly declines offers, it won't be re-offered the
>>> same resources for some period of time.
>>>
>>> On Sat, Jun 13, 2015 at 8:30 PM, Ondrej Smola 
>>> wrote:
>>>
 Hi Christopher,

 i dont know about any way way how to speed up first resource offer -
 in my experience new offers arrive almost immediately after framework
 registration. It depends on the infrastructure you are testing your
 framework on - are there any
 other frameworks running? As is discussed in an another thread offers
 should be send to multiple frameworks at once. There may be small
 delay based on initial registration and network delay. If you speak
 about "reoffers" - reoffering
 decline offers - there should param to set interval for reoffer. For
 example in Go you can decline offer this way (it is also important to
 decline every non used offer):

 driver.DeclineOffer(offer.Id, &mesos.Filters{RefuseSeconds:
 proto.Float64(5)})

 Look to mesos UI - it shoud give you information abou what offers are
 offered to which frameworks, mesos master logs also give you this
 information.


 2015-06-13 18:23 GMT+02:00 Christopher Ketchum :
 > Hi,
 >
 > I was wondering if there was any way to adjust the rate of resource
 offers to the framework. I am writing a mesos framework, and when I am
 testing it I am noticing a slight pause were the framework seems to be
 waiting for another resource offer. I would like to know if there is any
 way to speed these offers up, just to make testing a little faster.
 >
 > Thanks,
 > Chris

>>>
>>>
>>
>


--

Re: Threading model of mesos API (C++)

[Alexander Gallego]

Jim,

Let me prototype something small today. After reading my scheduler (in c++)
i do have comments and synchronization on some state vars, but it might
have to do with a more complex async code base I manage.

I'll get back to you.

- alex


On Wed, Jun 10, 2015 at 6:15 AM, James Vanns  wrote:

> Thanks for the responses, guys. That link of the 'detailed description'
> will be handy - I've not come across that before. I do now have another
> question though! Aren't these two a contradiction;
>
> Alex;
> "you launch a task, before the method returns (say you do some blocking
> stuff after, like sync update zookeeper), you might get a statusUpdate()
> callback."
> Ben;
> "Methods will not be invoked concurrently, and each method must complete
> before the next is called."
>
> ??
>
> Jim
>
>
> On 10 June 2015 at 02:22, Benjamin Mahler 
> wrote:
>
>> If that's really what you're seeing, it is a bug and a very surprising
>> one, so please provide evidence :)
>>
>> See the "detailed description" here:
>> http://mesos.apache.org/api/latest/c++/classmesos_1_1Scheduler.html
>>
>> The scheduler driver will serially invoke methods on your Scheduler
>> implementation. Methods will not be invoked concurrently, and each method
>> must complete before the next is called.
>>
>> So, we recommend that you don't block inside the callbacks. Otherwise,
>> you're blocking the driver as well and your own ability to continue
>> processing callbacks.
>>
>> On Tue, Jun 9, 2015 at 8:58 AM, James Vanns  wrote:
>>
>>> Hi. I'm toying with the mesos scheduler (C++) API and running into
>>> unexpected race conditions. I have *not* synchronised access to attributes
>>> of my Scheduler-derived class. Is the mesos library code threaded and
>>> network communication asynchronous? What it *looks like* I'm seeing is my
>>> statusUpdate() callback being executed before the return of
>>> resourceOffers(). Naturally I call driver->launchTasks() inside
>>> resourceOffers(). This is intermittent but generally triggered by tasks
>>> that report status changes very quickly; eg. a task that fails instantly.
>>>
>>> Can anyone point me in the right direction of any online API docs that
>>> explain how callbacks are invoked? Distributed over a pool of worker
>>> threads?
>>>
>>> Also are the state transitions documented? Eg.
>>> mesos::TASK_STAGING -> mesos::TASK_STARTING -> etc.
>>>
>>> Cheers,
>>>
>>> Jim
>>>
>>> --
>>> Senior Code Pig
>>> Industrial Light & Magic
>>>
>>
>>
>
>
> --
> --
> Senior Code Pig
> Industrial Light & Magic
>

Re: Threading model of mesos API (C++)

[Alexander Gallego]

Jim,

You do need to do your own synchronization.

It's basically possible for ANY callback to call your code in any order.
The API does not guarantee ordering.

For example, say you launch a task, before the method returns (say you do
some blocking stuff after, like sync update zookeeper), you might get a
statusUpdate() callback.

Effectively, you have 3 steps.

1.  a list of tasks for things that are pending (not launched, not enough
resources yet)
2.  a list of tasks for things that have launched but not yet
'statusUpdate()'
3.  a form of persistent list (zk, mysql, whatev) for things that confirm
they are running if you need High Avail.






On Tue, Jun 9, 2015 at 12:02 PM, James Vanns  wrote:

> Replying to my own thread here ;) It is also possible that
> resourceOffers() is called more than once before the first statusUpdate()
> is received. That is more likely.
>
> Some links to state transitions, and any threading model would be handy
> though. Or at least how and when callbacks are invoked. Just so I know what
> I need to protect access to ;)
>
> Cheers,
>
> Jim
>
>
> On 9 June 2015 at 16:58, James Vanns  wrote:
>
>> Hi. I'm toying with the mesos scheduler (C++) API and running into
>> unexpected race conditions. I have *not* synchronised access to attributes
>> of my Scheduler-derived class. Is the mesos library code threaded and
>> network communication asynchronous? What it *looks like* I'm seeing is my
>> statusUpdate() callback being executed before the return of
>> resourceOffers(). Naturally I call driver->launchTasks() inside
>> resourceOffers(). This is intermittent but generally triggered by tasks
>> that report status changes very quickly; eg. a task that fails instantly.
>>
>> Can anyone point me in the right direction of any online API docs that
>> explain how callbacks are invoked? Distributed over a pool of worker
>> threads?
>>
>> Also are the state transitions documented? Eg.
>> mesos::TASK_STAGING -> mesos::TASK_STARTING -> etc.
>>
>> Cheers,
>>
>> Jim
>>
>> --
>> Senior Code Pig
>> Industrial Light & Magic
>>
>
>
>
> --
> --
> Senior Code Pig
> Industrial Light & Magic
>

Re: [DISCUSS] Renaming Mesos Slave

[Alexander Gallego]

1. mesos-worker
2. mesos-worker
3. yes
4. carefully

On Tue, Jun 2, 2015 at 1:15 PM, CCAAT  wrote:

> On 06/01/2015 04:18 PM, Adam Bordelon wrote:
>
>> There has been much discussion about finding a less offensive name than
>> "Slave", and many of these thoughts have been captured in
>> https://issues.apache.org/jira/browse/MESOS-1478
>>
>
> I find political correctness rather nausiating. Folks should stop
> trying to apologies for what others did, often hundreds of years ago.
> I was not part of that. The advanced education system, the political
> system and the current wealth control systems around the globe, are in fact
> and indeed "Master-Slave" relationships; so why cleanse this notion
> prematurely?
>
>
> Master-slave has a rich history in the entire field of compuatational
> resources and electronics. That usage has nothing to do with social
> conventions and failings of the past. So, if you want to do something
> effective for those of us less fortunate, why not use terms like
>
>
>
>
>
>
>  I would like to open up the discussion on this topic for one week, and
>> if we cannot arrive at a lazy consensus, I will draft a proposal from
>> the discussion and call for a VOTE.
>> Here are the questions I would like us to answer:
>> 1. What should we call the "Mesos Slave" node/host/machine?
>> 2. What should we call the "mesos-slave" process (could be the same)?
>>
> Elite-taxpayer  or  Lawyer-citizen or Billionare-wager  or
> Professor-debtor ?
>
>  Something more apropo?
>
>  3. Do we need to rename Mesos Master too?
>>
>
> The concept of a master has been around ever since (2) males or more
> graced this planet (your theories of soccial evilutoin may vary but they
> are irrelevant).
>
> Commander? General ? Generalisimo?   Master_Chief  Warlord?
>
> Why not get rid of the entire Apache evironment why you are at it?
> This line of reasoning is nothing but *STUPID*   You cannot errase
> the history of the warrior existence of mankind. Nor should any today
> apologize for historical convention. WE did not commit any bad deeds
> before we were born, so just get over it!
>
>
>
>  Another topic worth discussing is the deprecation process, but we don't
>> necessarily need to decide on that at the same time as deciding the new
>> name(s).
>> 4. How will we phase in the new name and phase out the old name?
>>
>> Please voice your thoughts and opinions below.
>>
>> Thanks!
>> -Adam-
>>
>> P.S. My personal thoughts:
>> 1. Mesos Worker [Node]
>> 2. Mesos Worker or Agent
>> 3. No
>> 4. Carefully
>>
>
>
> This is the sadest thread I have ever read.
>
> James
>
>
>

Re: How slaves calculate resources

[Alexander Gallego]

Basically all the info you need is in os.hpp in the stout lib of mesos.

Effectively, the cpus are just a syscall:

sysconf(_SC_NPROCESSORS_ONLN);


The memory on the other hand is calculated:


# if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 3, 23)
  memory.total = Bytes(info.totalram * info.mem_unit);
  memory.free = Bytes(info.freeram * info.mem_unit);
# else
  memory.total = Bytes(info.totalram);
  memory.free = Bytes(info.freeram);
# endif





On Thu, May 21, 2015 at 6:51 AM, Aaron Carey  wrote:

>  I've managed to increase the disksize by playing with some docker
> options,
>
> Anyone have any idea about the memory?
>
> Thanks,
> Aaron
>
>  --
> *From:* Aaron Carey [aca...@ilm.com]
> *Sent:* 21 May 2015 11:19
> *To:* user@mesos.apache.org
> *Subject:* How slaves calculate resources
>
>   Hi,
>
> I was just trying to figure out how Mesos slaves report the amount of
> resources available to them on the host?
>
> We have some slaves running on AWS t2.medium machines (2cpu, 4Gb RAM) with
> 32GB disks.
>
> The slaves are running inside docker containers.
>
> They report 2 cpus (correct), 2.5GB RAM and 4.9GB disk.
>
> Any ideas why this is different from what I can see on the machine? (both
> on the host and within the slave docker container)?
>
> Thanks,
> Aaron
>



-- 





Sincerely,
Alexander Gallego
Co Founder & CTO

Re: Error when creating a new HA cluster on EC2

[Alexander Gallego]

James,

It is incredibly challenging to build everything from scratch.

To build mesos from 100% sources as you propose you'll need to find **all**
transitive dependencies first. Each in turn will have transitive deps.

In fact, if you look at the build system the reason leveldb.patch exist is
to attempt and reduce that complexity.

```
+# Removed tests for TCMALLOC and SNAPPY to prevent additional dependencies.
```

Most linux packages exist **exactly** for that reason. It is not easy to
build native dependencies and have it work for your operating system.
That's what apt-* is for ubuntu for exapmle.


Now building **just mesos** from sources is quite trivial.


Here is my entire ansible build for my local dev box

```


- name: configure mesos
  shell: "LIBS=-lglog LDFLAGS=-L/usr/local/lib
{{bolt_cache_dir}}/{{mesos_dir}}/configure
--with-glog=/usr/local
--disable-python
--disable-java"

  args:
creates: '{{bolt_cache_dir}}/{{mesos_dir}}/build/Makefile'
chdir: '{{bolt_cache_dir}}/{{mesos_dir}}/build'

- name: Make mesos
  sudo: True
  shell:
"ldconfig && make -j{{ansible_processor_vcpus}}"
  args:
chdir: '{{bolt_cache_dir}}/{{mesos_dir}}/build'
creates: '{{bolt_cache_dir}}/{{mesos_dir}}/build/src/libmesos.la'



```


If you ever participated in large scale native builds, you might know that
compiler flags and linker flags have a huge effect on whether the software
will work at runtime (i.e: symbols stripped away, extern functions not
being exported for weird reasons, ABI incompatibility, etc).

To be honest, building everything from source sounds impractical unless you
have a team of developers optimizing it for your platform. Your
dependencies would be an explosion of build system system deps - CMAKE,
autoconf, Scons, at the top of my head for transitive deps.

As I said, that is exactly my ansible task for building mesos locally. Hope
it helps.

-ag






Sincerely,
Alexander Gallego


On Sun, Feb 22, 2015 at 3:11 PM, CCAAT  wrote:

> On 02/22/2015 06:35 AM, i...@roybos.nl wrote:
>
>  Last friday i put some Ansible scripts on github for provisoning a multi
>> AZ cluster on AWS.
>> You could have a look at it
>> https://github.com/roybos/aws-mesos-marathon-cluster and maybe it helps
>> you.
>>
>> It basically creates a VPC within an AWS region and setups 1 node in 3
>> AZ's.
>> All nodes are currently equal(mesos master and slave are on the same
>> machine) which is fine for smaller clusters for let's say 3 to 30 nodes.
>>
>> Roy Bos
>>
>
> Very cool. I'm new to ansible, but I like what I've learns so far.
> What would be cool is if some thing like this ansible example was for
> just 3 (generic linux ) system that are installed  from sources. No
> binaries, no distro specific packages, just pure, raw sources. That
> way it would provide a baseline for installation on all sorts of linux
> (embedded, vm, container, uncommon_distro, different architectures like
> arm64 etc etc) based systems.
>
>
> Any ansible guides for generic mesos installs from sources would be
> of keen interests to many folks.
>
> After that in-house from sources methodology is viable, I'm quite certain
> companies will want to augment their local (in-house) cluster resources,
> with resources from vendors, particularly in a dynamic mode of utilization.
> Therefore, within the  in-house resources mixed (supplemented) with vendor
> resources is the future of cluster computing. ymmv.
>
> Sadly, I see little progress on this open systems approach, and that
> concerns me greatly for the viability of the mesos cluster. Is it indeed
> going to be limited to large corporations trying to sell something nobody
> wants; or are there going to be open source methodologies developed that
> streamline the installation of mesos
> inside of a medium size company with modest resources.
>
> Ansible is the key technology here combined with building up a mesos
> cluster FROM 100% SOURCES.
>
>
> Put that in your presentation at mesos con(artists?)
>
>
> James
>
>
>
>
>

Re: Difficulties building mesos-21.1-rc2 {rc1, .1 , .0}. Linux

[Alexander Gallego]

Thanks Cody. 

I'll start work from the master branch on github and see how far I get. 

I guess we'll just need to ensure stout,http parser, etc are copied to 
/usr/local and have our own build of mesos. 

Thanks again for your help. Are there specific Jira issues I can monitor? I'm 
building a messaging infrastructure and mesos is the foundation.

-ag

Sent from my iPhone

> On Feb 4, 2015, at 8:32 PM, Cody Maloney  wrote:
> 
> Some of the --with options are broken, and others have only been recently 
> fixed. The best option with 0.21.1 is to use --disable-bundled at which point 
> your system search paths just need to be configured correctly to find 
> everything.
> 
> The story around the `--with-{glog,zlib,curl,sasl}` and the like should be 
> getting better with 0.22.0 because people are working on building mesos 
> modules outside of the mesos source tree, which requires the module and mesos 
> use the same version of dependent libraries in many cases.
> 
> 
>> On Wed, Feb 4, 2015 at 5:26 PM, Alexander Gallego  
>> wrote:
>> In fact, I took the one from inside mesos (didn't apply the .patch file 
>> though), but other libs depend on it, that don't depend on mesos (i.e. 
>> fbthrif )
>> 
>> 
>> 
>> Sincerely, 
>> Alexander Gallego
>> 
>> 
>>> On Wed, Feb 4, 2015 at 8:24 PM, Alexander Gallego  
>>> wrote:
>>> Ian, 
>>> 
>>> Thanks for taking a look. I am running 0.3.3 (latest i think)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Sincerely, 
>>> Alexander Gallego
>>> 
>>> 
>>>> On Wed, Feb 4, 2015 at 8:09 PM, Ian Downes  wrote:
>>>> What version of glog are you trying to us? It appears the 
>>>> CheckOpMessageBuilder class was introduced in 0.3.3
>>>> 
>>>> http://upstream.rosalinux.ru/compat_reports/glog/0.3.2_to_0.3.3/abi_compat_report.html
>>>> 
>>>>> On Wed, Feb 4, 2015 at 4:52 PM, Alexander Gallego  
>>>>> wrote:
>>>>> I did a little more exploration and to be concise, this is more or less 
>>>>> what I want
>>>>> 
>>>>> (valid configuration)
>>>>> 
>>>>> ./configure \
>>>>> --with-gnu-ld \
>>>>> --enable-static=no \
>>>>> --with-gmock=/home/agallego/.bolt/gmock-1.6.0 \
>>>>> --with-glog=/usr/local \
>>>>> --with-zlib=/usr/local \
>>>>> --with-sasl=/usr/local \
>>>>> --with-curl=/usr/local \
>>>>> --with-zookeeper=/usr/local \
>>>>> --enable-optimize"
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Attached is my Makefile (./configure generates)  & the error log (glog 
>>>>> mentioned in my earlier gist)
>>>>> 
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Sincerely, 
>>>>> Alexander Gallego
>>>>> 
>>>>> 
>>>>>> On Wed, Feb 4, 2015 at 4:28 PM, Alexander Gallego  
>>>>>> wrote:
>>>>>> I wanted to post configuration formatted, so gisted my issue. 
>>>>>> 
>>>>>> Thank you in advance.
>>>>>> 
>>>>>> https://gist.github.com/senior7515/bc1a03edcbbe9b7cd7bf
>>>>>> 
>>>>>> 
>>>>>> Not sure if I should inline the question too. Tips appreciated. 
>>>>>> 
>>>>>> -ag
>>>>>> 
>>>>>> Sincerely, 
>>>>>> Alexander Gallego
> 

Re: Difficulties building mesos-21.1-rc2 {rc1, .1 , .0}. Linux

[Alexander Gallego]

In fact, I took the one from inside mesos (didn't apply the .patch file
though), but other libs depend on it, that don't depend on mesos (i.e.
fbthrif )



Sincerely,
Alexander Gallego


On Wed, Feb 4, 2015 at 8:24 PM, Alexander Gallego 
wrote:

> Ian,
>
> Thanks for taking a look. I am running 0.3.3 (latest i think)
>
>
>
>
>
> Sincerely,
> Alexander Gallego
>
>
> On Wed, Feb 4, 2015 at 8:09 PM, Ian Downes  wrote:
>
>> What version of glog are you trying to us? It appears the
>> CheckOpMessageBuilder class was introduced in 0.3.3
>>
>>
>> http://upstream.rosalinux.ru/compat_reports/glog/0.3.2_to_0.3.3/abi_compat_report.html
>>
>> On Wed, Feb 4, 2015 at 4:52 PM, Alexander Gallego 
>> wrote:
>>
>>> I did a little more exploration and to be concise, this is more or less
>>> what I want
>>>
>>> (valid configuration)
>>>
>>> ./configure \
>>> --with-gnu-ld \
>>> --enable-static=no \
>>> --with-gmock=/home/agallego/.bolt/gmock-1.6.0 \
>>> --with-glog=/usr/local \
>>> --with-zlib=/usr/local \
>>> --with-sasl=/usr/local \
>>> --with-curl=/usr/local \
>>> --with-zookeeper=/usr/local \
>>> --enable-optimize"
>>>
>>>
>>>
>>>
>>>
>>> Attached is my Makefile (./configure generates)  & the error log (glog
>>> mentioned in my earlier gist)
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Sincerely,
>>> Alexander Gallego
>>>
>>>
>>> On Wed, Feb 4, 2015 at 4:28 PM, Alexander Gallego 
>>> wrote:
>>>
>>>> I wanted to post configuration formatted, so gisted my issue.
>>>>
>>>> Thank you in advance.
>>>>
>>>> https://gist.github.com/senior7515/bc1a03edcbbe9b7cd7bf
>>>>
>>>>
>>>> Not sure if I should inline the question too. Tips appreciated.
>>>>
>>>> -ag
>>>>
>>>> Sincerely,
>>>> Alexander Gallego
>>>>
>>>>
>>>
>>
>

Re: Difficulties building mesos-21.1-rc2 {rc1, .1 , .0}. Linux

[Alexander Gallego]

Ian,

Thanks for taking a look. I am running 0.3.3 (latest i think)





Sincerely,
Alexander Gallego


On Wed, Feb 4, 2015 at 8:09 PM, Ian Downes  wrote:

> What version of glog are you trying to us? It appears the
> CheckOpMessageBuilder class was introduced in 0.3.3
>
>
> http://upstream.rosalinux.ru/compat_reports/glog/0.3.2_to_0.3.3/abi_compat_report.html
>
> On Wed, Feb 4, 2015 at 4:52 PM, Alexander Gallego 
> wrote:
>
>> I did a little more exploration and to be concise, this is more or less
>> what I want
>>
>> (valid configuration)
>>
>> ./configure \
>> --with-gnu-ld \
>> --enable-static=no \
>> --with-gmock=/home/agallego/.bolt/gmock-1.6.0 \
>> --with-glog=/usr/local \
>> --with-zlib=/usr/local \
>> --with-sasl=/usr/local \
>> --with-curl=/usr/local \
>> --with-zookeeper=/usr/local \
>> --enable-optimize"
>>
>>
>>
>>
>>
>> Attached is my Makefile (./configure generates)  & the error log (glog
>> mentioned in my earlier gist)
>>
>>
>> Thanks!
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Sincerely,
>> Alexander Gallego
>>
>>
>> On Wed, Feb 4, 2015 at 4:28 PM, Alexander Gallego 
>> wrote:
>>
>>> I wanted to post configuration formatted, so gisted my issue.
>>>
>>> Thank you in advance.
>>>
>>> https://gist.github.com/senior7515/bc1a03edcbbe9b7cd7bf
>>>
>>>
>>> Not sure if I should inline the question too. Tips appreciated.
>>>
>>> -ag
>>>
>>> Sincerely,
>>> Alexander Gallego
>>>
>>>
>>
>

Re: Difficulties building mesos-21.1-rc2 {rc1, .1 , .0}. Linux

[Alexander Gallego]

I did a little more exploration and to be concise, this is more or less
what I want

(valid configuration)

./configure \
--with-gnu-ld \
--enable-static=no \
--with-gmock=/home/agallego/.bolt/gmock-1.6.0 \
--with-glog=/usr/local \
--with-zlib=/usr/local \
--with-sasl=/usr/local \
--with-curl=/usr/local \
--with-zookeeper=/usr/local \
--enable-optimize"





Attached is my Makefile (./configure generates)  & the error log (glog
mentioned in my earlier gist)


Thanks!









Sincerely,
Alexander Gallego


On Wed, Feb 4, 2015 at 4:28 PM, Alexander Gallego 
wrote:

> I wanted to post configuration formatted, so gisted my issue.
>
> Thank you in advance.
>
> https://gist.github.com/senior7515/bc1a03edcbbe9b7cd7bf
>
>
> Not sure if I should inline the question too. Tips appreciated.
>
> -ag
>
> Sincerely,
> Alexander Gallego
>
>
Making all in .
make[1]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build'
Making all in 3rdparty
make[1]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty'
make  all-recursive
make[2]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty'
Making all in libprocess
make[3]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess'
Making all in 3rdparty
make[4]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/3rdparty'
make  all-recursive
make[5]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/3rdparty'
Making all in stout
make[6]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/3rdparty/stout'
Making all in .
make[7]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/3rdparty/stout'
make[7]: Nothing to be done for `all-am'.
make[7]: Leaving directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/3rdparty/stout'
Making all in include
make[7]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/3rdparty/stout/include'
make[7]: Nothing to be done for `all'.
make[7]: Leaving directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/3rdparty/stout/include'
make[6]: Leaving directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/3rdparty/stout'
make[6]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/3rdparty'
make[6]: Nothing to be done for `all-am'.
make[6]: Leaving directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/3rdparty'
make[5]: Leaving directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/3rdparty'
make[4]: Leaving directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/3rdparty'
Making all in .
make[4]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess'
Making all in include
make[4]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/include'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess/include'
make[3]: Leaving directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty/libprocess'
make[3]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty'
make[2]: Leaving directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty'
make[1]: Leaving directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/3rdparty'
Making all in src
make[1]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/src'
make  all-am
make[2]: Entering directory `/home/agallego/.bolt/mesos-0.21.1-rc2/build/src'
/bin/bash ../libtool  --tag=CXX   --mode=link g++ -pthread -O2 -Wno-unused-local-typedefs -std=c++11  -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib  -L/usr/local/lib -L/usr/local/lib -o mesos-local local/mesos_local-main.o libmesos.la -lsasl2 -lsvn_delta-1 -lsvn_subr-1 -lapr-1 -lcurl -lz  -lrt -lunwind
libtool: link: g++ -pthread -O2 -Wno-unused-local-typedefs -std=c++11 -o .libs/mesos-local local/mesos_local-main.o  -L/usr/local/lib ./.libs/libmesos.so -lsasl2 /usr/lib/x86_64-linux-gnu/libsvn_delta-1.so /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so /usr/lib/x86_64-linux-gnu/libapr-1.so /usr/lib/x86_64-linux-gnu/libcurl.so -lz -lrt -lunwind -pthread
local/mesos_local-main.o:main.cp

Difficulties building mesos-21.1-rc2 {rc1, .1 , .0}. Linux

[Alexander Gallego]

I wanted to post configuration formatted, so gisted my issue.

Thank you in advance.

https://gist.github.com/senior7515/bc1a03edcbbe9b7cd7bf


Not sure if I should inline the question too. Tips appreciated.

-ag

Sincerely,
Alexander Gallego

Re: Difficulties building libmesos.so

[Alexander Gallego]

Hi Tim,

Thanks for the reply and apologies for the late response - gmail filter was
pretty aggressive.

At the moment I have a less than Ideal setup - a hack -, but the work
around is to essentially remove libproto, libzookeeper from my libs when
linking against libmesos

Given that we happen to run the same version, is just a plain coincidence.
It would be great if libmesos can build as a normal dynamic lib as opposed
to a statically linked library. This gives me greater flexibility to
provide for example - patched versions of a protobuf or zookeepr libs etc.

Thanks!





Sincerely,
Alexander Gallego

---*---
--*
*  *  *




On Mon, Jun 16, 2014 at 4:49 PM, Tim St Clair  wrote:

> Greetings Alexandar -
>
> My apologies for my delayed response, I've been inundated as of late.
>
> ./configure --disable-bundled
>
> is the easiest option if you have a system installed version of the
> libraries, but it doesn't yet handle protobuf.
>
> I'm not entirely certain where ubuntu is @ with regard to the full
> dep-graph, but it is available in fedora channels.
>
> You could also try https://github.com/timothysc/mesos/tree/0.18-integ if
> you're willing to live behind the times for a bit.
>
> I'm going to make a hard push to get --disable-bundled fully completed
> prior to a 1.0 release/MesosCon.
>
> Cheers,
> Tim
>
> --
>
> *From: *"Alexander Gallego" 
> *To: *user@mesos.apache.org
> *Sent: *Sunday, June 8, 2014 12:55:56 AM
> *Subject: *Difficulties building libmesos.so
>
>
> I'm having a hard time attempting to use libmesos.so and hoping for
> guidance.
>
> Issue:
>
> Libmesos.so as installed by the mesosphere .deb pkg or built from source
> statically links all sources including:
>
> 1. Protobuf (2.5)
> 2. Zookeeper (3.4.5)
>
> This is a problem because when you start any int main(args, char**) it is
> suggested by the protobuf to initialize it for proper behavior. (check
> versions)
>
> Here is the snippet from source:
>
> build/include/google/protobuf/stubs/common.h
> 149:#define GOOGLE_PROTOBUF_VERIFY_VERSION
> // Place this macro in your main() function (or somewhere before you
> attempt
> // to use the protobuf library) to verify that the version you link against
> // matches the headers you compiled against.  If a version mismatch is
> // detected, the process will abort.
> #define GOOGLE_PROTOBUF_VERIFY_VERSION\
>   ::google::protobuf::internal::VerifyVersion(\
> GOOGLE_PROTOBUF_VERSION, GOOGLE_PROTOBUF_MIN_LIBRARY_VERSION, \
> __FILE__)
>
> To deinitialize the library  you are suggested you call 'shutdown'
>
> build/include/google/protobuf/stubs/common.cc
> void ShutdownProtobufLibrary() {
>   internal::InitShutdownFunctionsOnce();
>   // ... stuff
> }
>
> Well the issue is that when linking w/ libmesos (the static fat lib 298MB
> as of rc3)
> my protobufs now double free :(
>
> I haven't yet been able to play w/ zookeeper and its internal state as it
> interacts w/
> libmesos.so. The issue is fundamentally static state (ugh). But I have to
> use
> these libs (zookeeper, protobuf) for a project.
>
>
> The tentative solution suggested (mesos/docs/configuration.md) is
> to use the compile time flags --with-zookeeper=/path/to/root/not/src/c
> *this is where i'd like guidance*
>
> I have not been able to compile libmesos as a lib without statically
> linking all the deps
>
> Note: I have read the mainling list post describing why the build system
> was originally
> set up this way (mainly that there are patches -- look at the .patch files)
>
>
> Things I've done to try and build libmesos.so without statically linking
> protobufs, boost, zookeeper:
>
>
> Here are the command line args passing to configure:
>
> // assume TLD=/absolute/path/to/libs
>
> ./configure --enable-shared=yes \
> --enable-bundled=no \
> --disable-python\
> --with-zookeeper="${TLD}/zookeeper" \
> --with-leveldb="${TLD}/leveldb"
>
> The first problem is that passing just -with-leveldb= to the dir w/
> leveldb for example
> doesn't find the -lleveldb.
>
> I tried looking at the make file and the paths seem correct mainly:
>
> Lines 129 & 130 (I guess this might change from system to system)
> am__append_2 = $(LEVELDB)/libleveldb.a
> am__append_3 = $(ZOOKEEPER)/src/c/libzookeeper_mt.la
>
>
> Notes about my desktop system:
>
> Using gcc 4.8
> $ lsb_release -a
> Distributor ID: Ubuntu
> Descrip

Difficulties building libmesos.so

[Alexander Gallego]

I'm having a hard time attempting to use libmesos.so and hoping for
guidance.

Issue:

Libmesos.so as installed by the mesosphere .deb pkg or built from source
statically links all sources including:

1. Protobuf (2.5)
2. Zookeeper (3.4.5)

This is a problem because when you start any int main(args, char**) it is
suggested by the protobuf to initialize it for proper behavior. (check
versions)

Here is the snippet from source:

build/include/google/protobuf/stubs/common.h
149:#define GOOGLE_PROTOBUF_VERIFY_VERSION
// Place this macro in your main() function (or somewhere before you attempt
// to use the protobuf library) to verify that the version you link against
// matches the headers you compiled against.  If a version mismatch is
// detected, the process will abort.
#define GOOGLE_PROTOBUF_VERIFY_VERSION\
  ::google::protobuf::internal::VerifyVersion(\
GOOGLE_PROTOBUF_VERSION, GOOGLE_PROTOBUF_MIN_LIBRARY_VERSION, \
__FILE__)

To deinitialize the library  you are suggested you call 'shutdown'

build/include/google/protobuf/stubs/common.cc
void ShutdownProtobufLibrary() {
  internal::InitShutdownFunctionsOnce();
  // ... stuff
}

Well the issue is that when linking w/ libmesos (the static fat lib 298MB
as of rc3)
my protobufs now double free :(

I haven't yet been able to play w/ zookeeper and its internal state as it
interacts w/
libmesos.so. The issue is fundamentally static state (ugh). But I have to
use
these libs (zookeeper, protobuf) for a project.


The tentative solution suggested (mesos/docs/configuration.md) is
to use the compile time flags --with-zookeeper=/path/to/root/not/src/c
*this is where i'd like guidance*

I have not been able to compile libmesos as a lib without statically
linking all the deps

Note: I have read the mainling list post describing why the build system
was originally
set up this way (mainly that there are patches -- look at the .patch files)


Things I've done to try and build libmesos.so without statically linking
protobufs, boost, zookeeper:


Here are the command line args passing to configure:

// assume TLD=/absolute/path/to/libs

./configure --enable-shared=yes \
--enable-bundled=no \
--disable-python\
--with-zookeeper="${TLD}/zookeeper" \
--with-leveldb="${TLD}/leveldb"

The first problem is that passing just -with-leveldb= to the dir w/ leveldb
for example
doesn't find the -lleveldb.

I tried looking at the make file and the paths seem correct mainly:

Lines 129 & 130 (I guess this might change from system to system)
am__append_2 = $(LEVELDB)/libleveldb.a
am__append_3 = $(ZOOKEEPER)/src/c/libzookeeper_mt.la


Notes about my desktop system:

Using gcc 4.8
$ lsb_release -a
Distributor ID: Ubuntu
Description:Ubuntu 14.04 LTS
Release:14.04
Codename:   trusty


The questions i'm looking to get some pointers are:

* Has anyone actually built a shared libmesos.so without included
dependencies, if so, how.

* Is there a pre-build binaries (lib mesos w/out deps) for linux x86_64
systems avail for download
  perhaps the mesosphere guys have some solution here.

* How have other people building native apps (c++) linked and used
libmesos.so in their projects
  successfully? (either remove their versions of the lib and be forced to
use libmesos.so or ...?)



Kindly let me know if I can provide clarification.

Thanks in advance for reading.
-Alex



Sincerely,
Alexander Gallego

---*---
--*
*  *  *