Re: Mesos language bindings in the wild
Very exciting. I'd vote +1 for splitting them out. Especially if you look at the common way of using Go imports, just stick the project on GitHub and import it directly using "github.com/mesos/mesos-go" or similar. I guess one argument is that you have more fragmentation of the code (e.g every library has it's own copy of the protos) but I'm not sure that's a bad thing. Just my two cents. Looking forward to this! > On 11 Jul 2014, at 16:59, Thomas Rampelberg wrote: > > I've started preparing the python bindings to hopefully take this > route ( https://reviews.apache.org/r/23224/ would love some reviews! > ). In fact, there is already a native python implementation of both > libprocess and the framework apis! (https://github.com/wickman/pesos/ > , https://github.com/wickman/compactor ). > > What are the benefits of bindings being part of the project source > itself instead of having blessed implementations like mesos-python > where the source and versioning becomes separate? I've been running > into difficulties making automake and python's build tools play nicely > together. It seems like there'd be more flexibility in general by > splitting them out. > > >> On Thu, Jul 10, 2014 at 3:57 PM, Niklas Nielsen wrote: >> I just wanted to clarify - native, meaning _no_ dependency to libmesos and >> native to its language (only Go, only Python and so on) i.e. use the >> low-level API. >> >> Sorry for the confusion, >> Niklas >> >> >>> On 10 July 2014 15:55, Dominic Hamon wrote: >>> >>> In my dream world, we wouldn't need any native bindings. I can imagine >>> having example frameworks or starter frameworks that use the low-level API >>> (the wire protocol with protocol buffers for message passing), but nothing >>> like we have that needs C or JNI, etc. >>> >>> >>> >>> >>> On Thu, Jul 10, 2014 at 3:26 PM, Niklas Nielsen >>> wrote: >>> Hi all, I wanted to start a discussion around the language bindings in the wild (Go, Haskell, native Python, Go, Java and so on) and possibly get to a strategy where we start bringing those into Mesos proper. As most things points towards, it will probably make sense to focus on the native "bindings" leveraging the low-level API. To name one candidate to start with, we are especially interested in getting Go native support in Mesos proper (and in a solid state). So Vladimir, we'd be super thrilled to >>> start collaborating with you on your current work. We are interested to hear what thoughts you all might have on this. Thanks, Niklas >>>
Re: Mesos language bindings in the wild
I'm a fan of splitting these things out as you end up with various implementations, some of which will be more suited for some applications that others. It also encourages exploration of the API in various ways. As an aside, I've been playing with a go version too at https://github.com/dominichamon/gozer. It's not meant to be anything but an API test-case. On Fri, Jul 11, 2014 at 8:22 AM, Tom Arnfeld wrote: > Very exciting. I'd vote +1 for splitting them out. Especially if you > look at the common way of using Go imports, just stick the project on > GitHub and import it directly using "github.com/mesos/mesos-go" or > similar. > > I guess one argument is that you have more fragmentation of the code > (e.g every library has it's own copy of the protos) but I'm not sure > that's a bad thing. > > Just my two cents. Looking forward to this! > > > On 11 Jul 2014, at 16:59, Thomas Rampelberg wrote: > > > > I've started preparing the python bindings to hopefully take this > > route ( https://reviews.apache.org/r/23224/ would love some reviews! > > ). In fact, there is already a native python implementation of both > > libprocess and the framework apis! (https://github.com/wickman/pesos/ > > , https://github.com/wickman/compactor ). > > > > What are the benefits of bindings being part of the project source > > itself instead of having blessed implementations like mesos-python > > where the source and versioning becomes separate? I've been running > > into difficulties making automake and python's build tools play nicely > > together. It seems like there'd be more flexibility in general by > > splitting them out. > > > > > >> On Thu, Jul 10, 2014 at 3:57 PM, Niklas Nielsen > wrote: > >> I just wanted to clarify - native, meaning _no_ dependency to libmesos > and > >> native to its language (only Go, only Python and so on) i.e. use the > >> low-level API. > >> > >> Sorry for the confusion, > >> Niklas > >> > >> > >>> On 10 July 2014 15:55, Dominic Hamon wrote: > >>> > >>> In my dream world, we wouldn't need any native bindings. I can imagine > >>> having example frameworks or starter frameworks that use the low-level > API > >>> (the wire protocol with protocol buffers for message passing), but > nothing > >>> like we have that needs C or JNI, etc. > >>> > >>> > >>> > >>> > >>> On Thu, Jul 10, 2014 at 3:26 PM, Niklas Nielsen > >>> wrote: > >>> > Hi all, > > I wanted to start a discussion around the language bindings in the > wild > (Go, Haskell, native Python, Go, Java and so on) and possibly get to a > strategy where we start bringing those into Mesos proper. As most > things > points towards, it will probably make sense to focus on the native > "bindings" leveraging the low-level API. To name one candidate to > start > with, we are especially interested in getting Go native support in > Mesos > proper (and in a solid state). So Vladimir, we'd be super thrilled to > >>> start > collaborating with you on your current work. > > We are interested to hear what thoughts you all might have on this. > > Thanks, > Niklas > >>> > -- Dominic Hamon | @mrdo | Twitter *There are no bad ideas; only good ideas that go horribly wrong.*
Re: Mesos language bindings in the wild
I'm a fan of splitting these things out as you end up with various implementations, some of which will be more suited for some applications that others. It also encourages exploration of the API in various ways. As an aside, I've been playing with a go version too at https://github.com/dominichamon/gozer. It's not meant to be anything but an API test-case. On Fri, Jul 11, 2014 at 8:22 AM, Tom Arnfeld wrote: > Very exciting. I'd vote +1 for splitting them out. Especially if you > look at the common way of using Go imports, just stick the project on > GitHub and import it directly using "github.com/mesos/mesos-go" or > similar. > > I guess one argument is that you have more fragmentation of the code > (e.g every library has it's own copy of the protos) but I'm not sure > that's a bad thing. > > Just my two cents. Looking forward to this! > > > On 11 Jul 2014, at 16:59, Thomas Rampelberg wrote: > > > > I've started preparing the python bindings to hopefully take this > > route ( https://reviews.apache.org/r/23224/ would love some reviews! > > ). In fact, there is already a native python implementation of both > > libprocess and the framework apis! (https://github.com/wickman/pesos/ > > , https://github.com/wickman/compactor ). > > > > What are the benefits of bindings being part of the project source > > itself instead of having blessed implementations like mesos-python > > where the source and versioning becomes separate? I've been running > > into difficulties making automake and python's build tools play nicely > > together. It seems like there'd be more flexibility in general by > > splitting them out. > > > > > >> On Thu, Jul 10, 2014 at 3:57 PM, Niklas Nielsen > wrote: > >> I just wanted to clarify - native, meaning _no_ dependency to libmesos > and > >> native to its language (only Go, only Python and so on) i.e. use the > >> low-level API. > >> > >> Sorry for the confusion, > >> Niklas > >> > >> > >>> On 10 July 2014 15:55, Dominic Hamon wrote: > >>> > >>> In my dream world, we wouldn't need any native bindings. I can imagine > >>> having example frameworks or starter frameworks that use the low-level > API > >>> (the wire protocol with protocol buffers for message passing), but > nothing > >>> like we have that needs C or JNI, etc. > >>> > >>> > >>> > >>> > >>> On Thu, Jul 10, 2014 at 3:26 PM, Niklas Nielsen > >>> wrote: > >>> > Hi all, > > I wanted to start a discussion around the language bindings in the > wild > (Go, Haskell, native Python, Go, Java and so on) and possibly get to a > strategy where we start bringing those into Mesos proper. As most > things > points towards, it will probably make sense to focus on the native > "bindings" leveraging the low-level API. To name one candidate to > start > with, we are especially interested in getting Go native support in > Mesos > proper (and in a solid state). So Vladimir, we'd be super thrilled to > >>> start > collaborating with you on your current work. > > We are interested to hear what thoughts you all might have on this. > > Thanks, > Niklas > >>> >
Re: Mesos language bindings in the wild
Embraced language repos is a great path too. +1 for not having to tie automake into the respective language build systems. Ensuring that they all work together when Mesos is changing becomes a bit more difficult, but not worse than CI'ing builds of the respective "bindings" against HEAD (is "bindings" the proper term for the native / non-libmesos dependent / low-level API language support?). However, is github.com/mesos a part of the ASF realm? Is it a common practice to do this? Niklas On 11 July 2014 08:37, Thomas Rampelberg wrote: > > I guess one argument is that you have more fragmentation of the code > > (e.g every library has it's own copy of the protos) but I'm not sure > > that's a bad thing. > > I'd planned on having mesos be a submodule. That way, you'll get the > correct protos without any duplication. >
mesos isolation
Hi, I am running a job on few machines in my Linux cluster. Each machine is an Intel 8 core (with 32 threads). I see a total of 32 CPUs in /etc/cpuinfo and within mesos web interface. When I launch a job using mesos, I see that all CPUs are used equally and not just the number of CPUs I specify for that task. Furthermore, I also see that the average per task running time within a single machine, with 5 tasks/machine is 1/2 as much as that with 10 tasks/machine. Within mesos, each task has 1 CPU assigned and it is completely CPU bound (no dataset, no file access). As per mesos, the 5 tasks job uses 5 CPUs while the 10 task job uses 10 CPUs (so average task run times should be same unlike what I am seeing). Also, when I monitor CPU utilization, I see that all CPUs are used equally. I am really confused. Is this how mesos/container isolation is supposed to work? Thanks, Asim
Re: mesos isolation
Are you using cgroups, or the default (posix) isolation? On 11 July 2014 17:06, Asim wrote: > Hi, > > I am running a job on few machines in my Linux cluster. Each machine is an > Intel 8 core (with 32 threads). I see a total of 32 CPUs in /etc/cpuinfo and > within mesos web interface. When I launch a job using mesos, I see that all > CPUs are used equally and not just the number of CPUs I specify for that > task. > > Furthermore, I also see that the average per task running time within a > single machine, with 5 tasks/machine is 1/2 as much as that with 10 > tasks/machine. Within mesos, each task has 1 CPU assigned and it is > completely CPU bound (no dataset, no file access). As per mesos, the 5 tasks > job uses 5 CPUs while the 10 task job uses 10 CPUs (so average task run > times should be same unlike what I am seeing). Also, when I monitor CPU > utilization, I see that all CPUs are used equally. I am really confused. Is > this how mesos/container isolation is supposed to work? > > Thanks, > Asim >
Re: mesos isolation
It will also matter if you are using systemd. Cheers, Tim - Original Message - > From: "Dick Davies" > To: user@mesos.apache.org > Sent: Friday, July 11, 2014 11:43:36 AM > Subject: Re: mesos isolation > > Are you using cgroups, or the default (posix) isolation? > > > > On 11 July 2014 17:06, Asim wrote: > > Hi, > > > > I am running a job on few machines in my Linux cluster. Each machine is an > > Intel 8 core (with 32 threads). I see a total of 32 CPUs in /etc/cpuinfo > > and > > within mesos web interface. When I launch a job using mesos, I see that all > > CPUs are used equally and not just the number of CPUs I specify for that > > task. > > > > Furthermore, I also see that the average per task running time within a > > single machine, with 5 tasks/machine is 1/2 as much as that with 10 > > tasks/machine. Within mesos, each task has 1 CPU assigned and it is > > completely CPU bound (no dataset, no file access). As per mesos, the 5 > > tasks > > job uses 5 CPUs while the 10 task job uses 10 CPUs (so average task run > > times should be same unlike what I am seeing). Also, when I monitor CPU > > utilization, I see that all CPUs are used equally. I am really confused. > > Is > > this how mesos/container isolation is supposed to work? > > > > Thanks, > > Asim > > > -- Cheers, Timothy St. Clair Red Hat Inc.
Re: Mesos language bindings in the wild
+1, esp re: Go. Test harness for language bindings will be pretty important. Cheers, Tim - Original Message - > From: "Niklas Nielsen" > To: "dev" > Cc: user@mesos.apache.org > Sent: Thursday, July 10, 2014 5:57:49 PM > Subject: Re: Mesos language bindings in the wild > I just wanted to clarify - native, meaning _no_ dependency to libmesos and > native to its language (only Go, only Python and so on) i.e. use the > low-level API. > Sorry for the confusion, > Niklas > On 10 July 2014 15:55, Dominic Hamon < dha...@twopensource.com > wrote: > > In my dream world, we wouldn't need any native bindings. I can imagine > > > having example frameworks or starter frameworks that use the low-level API > > > (the wire protocol with protocol buffers for message passing), but nothing > > > like we have that needs C or JNI, etc. > > > On Thu, Jul 10, 2014 at 3:26 PM, Niklas Nielsen < nik...@mesosphere.io > > > > wrote: > > > > Hi all, > > > > > > > > I wanted to start a discussion around the language bindings in the wild > > > > (Go, Haskell, native Python, Go, Java and so on) and possibly get to a > > > > strategy where we start bringing those into Mesos proper. As most things > > > > points towards, it will probably make sense to focus on the native > > > > "bindings" leveraging the low-level API. To name one candidate to start > > > > with, we are especially interested in getting Go native support in Mesos > > > > proper (and in a solid state). So Vladimir, we'd be super thrilled to > > > start > > > > collaborating with you on your current work. > > > > > > > > We are interested to hear what thoughts you all might have on this. > > > > > > > > Thanks, > > > > Niklas > > > > > -- Cheers, Timothy St. Clair Red Hat Inc.
Re: mesos isolation
Hi, I am using the default (posix) isolation. Also, I do not see the systemd running (not sure how that affects isolation). Thanks, Asim On Fri, Jul 11, 2014 at 12:46 PM, Tim St Clair wrote: > It will also matter if you are using systemd. > > Cheers, > Tim > > - Original Message - > > From: "Dick Davies" > > To: user@mesos.apache.org > > Sent: Friday, July 11, 2014 11:43:36 AM > > Subject: Re: mesos isolation > > > > Are you using cgroups, or the default (posix) isolation? > > > > > > > > On 11 July 2014 17:06, Asim wrote: > > > Hi, > > > > > > I am running a job on few machines in my Linux cluster. Each machine > is an > > > Intel 8 core (with 32 threads). I see a total of 32 CPUs in > /etc/cpuinfo > > > and > > > within mesos web interface. When I launch a job using mesos, I see > that all > > > CPUs are used equally and not just the number of CPUs I specify for > that > > > task. > > > > > > Furthermore, I also see that the average per task running time within a > > > single machine, with 5 tasks/machine is 1/2 as much as that with 10 > > > tasks/machine. Within mesos, each task has 1 CPU assigned and it is > > > completely CPU bound (no dataset, no file access). As per mesos, the 5 > > > tasks > > > job uses 5 CPUs while the 10 task job uses 10 CPUs (so average task run > > > times should be same unlike what I am seeing). Also, when I monitor CPU > > > utilization, I see that all CPUs are used equally. I am really > confused. > > > Is > > > this how mesos/container isolation is supposed to work? > > > > > > Thanks, > > > Asim > > > > > > > -- > Cheers, > Timothy St. Clair > Red Hat Inc. >
Re: mesos isolation
The posix/cpu isolator doesn't actually do any isolation - it only is useful to report cpu utilization. If you want to constrain the amount of cpu available to each container you must use the cgroups/cpu isolator. Is there any reason preventing you from using the cgroups cpu and memory isolators? Ian On Fri, Jul 11, 2014 at 10:55 AM, Asim wrote: > Hi, > > I am using the default (posix) isolation. Also, I do not see the systemd > running (not sure how that affects isolation). > > > Thanks, > Asim > > > > On Fri, Jul 11, 2014 at 12:46 PM, Tim St Clair wrote: >> >> It will also matter if you are using systemd. >> >> Cheers, >> Tim >> >> - Original Message - >> > From: "Dick Davies" >> > To: user@mesos.apache.org >> > Sent: Friday, July 11, 2014 11:43:36 AM >> > Subject: Re: mesos isolation >> > >> > Are you using cgroups, or the default (posix) isolation? >> > >> > >> > >> > On 11 July 2014 17:06, Asim wrote: >> > > Hi, >> > > >> > > I am running a job on few machines in my Linux cluster. Each machine >> > > is an >> > > Intel 8 core (with 32 threads). I see a total of 32 CPUs in >> > > /etc/cpuinfo >> > > and >> > > within mesos web interface. When I launch a job using mesos, I see >> > > that all >> > > CPUs are used equally and not just the number of CPUs I specify for >> > > that >> > > task. >> > > >> > > Furthermore, I also see that the average per task running time within >> > > a >> > > single machine, with 5 tasks/machine is 1/2 as much as that with 10 >> > > tasks/machine. Within mesos, each task has 1 CPU assigned and it is >> > > completely CPU bound (no dataset, no file access). As per mesos, the 5 >> > > tasks >> > > job uses 5 CPUs while the 10 task job uses 10 CPUs (so average task >> > > run >> > > times should be same unlike what I am seeing). Also, when I monitor >> > > CPU >> > > utilization, I see that all CPUs are used equally. I am really >> > > confused. >> > > Is >> > > this how mesos/container isolation is supposed to work? >> > > >> > > Thanks, >> > > Asim >> > > >> > >> >> -- >> Cheers, >> Timothy St. Clair >> Red Hat Inc. > >
Re: mesos isolation
> Is there any reason preventing you from using the cgroups cpu and >memory isolators? yes -- the reason was ignorance. I was not aware cgroups are not enabled by default. I will enable cgroups now. Thanks for your response! Regards, Asim On Fri, Jul 11, 2014 at 2:12 PM, Ian Downes wrote: > The posix/cpu isolator doesn't actually do any isolation - it only is > useful to report cpu utilization. If you want to constrain the amount > of cpu available to each container you must use the cgroups/cpu > isolator. > > Ian > > On Fri, Jul 11, 2014 at 10:55 AM, Asim wrote: > > Hi, > > > > I am using the default (posix) isolation. Also, I do not see the systemd > > running (not sure how that affects isolation). > > > > > > Thanks, > > Asim > > > > > > > > On Fri, Jul 11, 2014 at 12:46 PM, Tim St Clair > wrote: > >> > >> It will also matter if you are using systemd. > >> > >> Cheers, > >> Tim > >> > >> - Original Message - > >> > From: "Dick Davies" > >> > To: user@mesos.apache.org > >> > Sent: Friday, July 11, 2014 11:43:36 AM > >> > Subject: Re: mesos isolation > >> > > >> > Are you using cgroups, or the default (posix) isolation? > >> > > >> > > >> > > >> > On 11 July 2014 17:06, Asim wrote: > >> > > Hi, > >> > > > >> > > I am running a job on few machines in my Linux cluster. Each machine > >> > > is an > >> > > Intel 8 core (with 32 threads). I see a total of 32 CPUs in > >> > > /etc/cpuinfo > >> > > and > >> > > within mesos web interface. When I launch a job using mesos, I see > >> > > that all > >> > > CPUs are used equally and not just the number of CPUs I specify for > >> > > that > >> > > task. > >> > > > >> > > Furthermore, I also see that the average per task running time > within > >> > > a > >> > > single machine, with 5 tasks/machine is 1/2 as much as that with 10 > >> > > tasks/machine. Within mesos, each task has 1 CPU assigned and it is > >> > > completely CPU bound (no dataset, no file access). As per mesos, > the 5 > >> > > tasks > >> > > job uses 5 CPUs while the 10 task job uses 10 CPUs (so average task > >> > > run > >> > > times should be same unlike what I am seeing). Also, when I monitor > >> > > CPU > >> > > utilization, I see that all CPUs are used equally. I am really > >> > > confused. > >> > > Is > >> > > this how mesos/container isolation is supposed to work? > >> > > > >> > > Thanks, > >> > > Asim > >> > > > >> > > >> > >> -- > >> Cheers, > >> Timothy St. Clair > >> Red Hat Inc. > > > > >
Re: Mesos language bindings in the wild
I wrote a Clojure binding that uses reflection ( https://github.com/dgrnbrg/clj-mesos) -- I think that most of the dynamic langs could use something like this to reduce the pain of building a binding against a specific version. I ended up writing a simple rule-system to generate the appropriate static/dynamic marshaller for each protobuf, based on its naming convention and type. On Fri, Jul 11, 2014 at 8:48 PM, Tim St Clair wrote: > +1, esp re: Go. > > Test harness for language bindings will be pretty important. > > Cheers, > Tim > > -- > > *From: *"Niklas Nielsen" > *To: *"dev" > *Cc: *user@mesos.apache.org > *Sent: *Thursday, July 10, 2014 5:57:49 PM > *Subject: *Re: Mesos language bindings in the wild > > > I just wanted to clarify - native, meaning _no_ dependency to libmesos and > native to its language (only Go, only Python and so on) i.e. use the > low-level API. > > Sorry for the confusion, > Niklas > > > On 10 July 2014 15:55, Dominic Hamon wrote: > >> In my dream world, we wouldn't need any native bindings. I can imagine >> having example frameworks or starter frameworks that use the low-level API >> (the wire protocol with protocol buffers for message passing), but nothing >> like we have that needs C or JNI, etc. >> >> >> >> >> On Thu, Jul 10, 2014 at 3:26 PM, Niklas Nielsen >> wrote: >> >> > Hi all, >> > >> > I wanted to start a discussion around the language bindings in the wild >> > (Go, Haskell, native Python, Go, Java and so on) and possibly get to a >> > strategy where we start bringing those into Mesos proper. As most things >> > points towards, it will probably make sense to focus on the native >> > "bindings" leveraging the low-level API. To name one candidate to start >> > with, we are especially interested in getting Go native support in Mesos >> > proper (and in a solid state). So Vladimir, we'd be super thrilled to >> start >> > collaborating with you on your current work. >> > >> > We are interested to hear what thoughts you all might have on this. >> > >> > Thanks, >> > Niklas >> > >> > > > > > -- > Cheers, > Timothy St. Clair > Red Hat Inc. >
Re: Mesos language bindings in the wild
Naming suggestion, let's call these "pure" language bindings. Native is overloaded. On Fri, Jul 11, 2014 at 8:40 AM, Niklas Nielsen wrote: > Embraced language repos is a great path too. +1 for not having to tie > automake into the respective language build systems. > Ensuring that they all work together when Mesos is changing becomes a bit > more difficult, but not worse than CI'ing builds of the respective > "bindings" against HEAD (is "bindings" the proper term for the native / > non-libmesos dependent / low-level API language support?). > > However, is github.com/mesos a part of the ASF realm? Is it a common > practice to do this? > > Niklas > > > On 11 July 2014 08:37, Thomas Rampelberg wrote: > >> > I guess one argument is that you have more fragmentation of the code >> > (e.g every library has it's own copy of the protos) but I'm not sure >> > that's a bad thing. >> >> I'd planned on having mesos be a submodule. That way, you'll get the >> correct protos without any duplication. >> > >
