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 lib
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/dominichamo
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/dominichamo
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 "bindin
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 fo
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 la
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
+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 wa
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 -
>
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?
> 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:
> Th
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 sta
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
13 matches
Mail list logo
