Hi,
I had a quick question about the external containerizer. I see that once
the Task is launched, the ECP can receive the update calls, and the
protobuf message passed to ECP with the update call is containerizer::Update
.
This protobuf has a Resources [list] field so does that mean Mesos might
Hi Diptanu,
That's correct, the ECP has the responsibility of updating the resource for a
container, and it will do as new tasks are launched and killed for an executor.
Since docker doesn't support this, our containerizer (Deimos does the same)
goes behind docker to the cgroup for the conta
Thanks for the explanation Tom, yeah I just figured that out by reading
your code! You're touching the memory.soft_limit_in_bytes and
memory.limit_in_bytes directly.
Still curios to understand in which situations Mesos Slave would call the
external containerizer to update the resource limits of a
When Mesos is asked to a launch a task (with either a custom Executor or the
built in CommandExecutor) it will first spawn the executor which _has_ to be a
system process, launched via command. This process will be launched inside of a
Docker container when using the previously mentioned contain
I don't mind helping out shepherding a release through for 0.21.1 though I
don't have committer rights.
--
Tom Arnfeld
Developer // DueDil
On Tue, Dec 2, 2014 at 10:44 PM, Benjamin Mahler
wrote:
> If anyone is interested in driving a 0.21.1 bug fix release, we could get
> bug fixes out mor
Thanks Cody, exactly the info I was looking for. Do you know which volumes
need mounting? Just the mesos data directories, or additional system
directories also?
On Tue, Dec 2, 2014 at 3:02 PM, Cody Maloney wrote:
> Mesos inside docker definitely can work. There are some issues with the
> slave
Not to put too fine a point on it, but how are folks planning on establishing
governance around the App Container spec?
https://github.com/coreos/rocket/issues/193
If the mesos community decides to leverage our own, how do we ensure that we
have say in the spec going forwards?
Cheers,
Tim
Hi Tim,
I see you've already commented on the rocket repo about this, and from
their messaging it aims to be independent which should be the whole point
of the open container spec.
I think the best way is just to be involved in the spec early on and
continue to do so while we move forward, and we
inline below
- Original Message -
> From: "Tim Chen"
> To: user@mesos.apache.org
> Cc: "dev"
> Sent: Wednesday, December 3, 2014 11:20:47 AM
> Subject: Re: Rocket
> Hi Tim,
> I see you've already commented on the rocket repo about this, and from their
> messaging it aims to be indepe
Hi Tim,
Definitely I agree, i think what I am getting at is that it's clear from the
conversation that a open governance is what they want from day one. Apache is
one of the options mentioned one the Issue, and I believe something along that
line is most probable.
As long as that's true it won
This may have to do with fine-grain Vs coarse-grain resource allocation.
Things may be easier for you, Diptanu, if you are using one Docker
container per task (sort of coarse grain). In that case, I believe there's
no need to alter a running Docker container's resources. Instead, the
resource updat
You're right Sharma, it's dependent upon the framework. If your scheduler sets
a unique ExecutorID for each TaskInfo, then the executor will not be re-used
and you won't have to worry about resizing the executor's container to
accomodate subsequent tasks. This might be a reasonable simplificat
Yes, although, there's a nuance to this specific situation. Here, the same
executor is being used for multiple tasks, but, the executor is launching a
different Docker container for each task. I was extending the coarse grain
allocation concept to within the executor (which is in a fine grained
all
Tim and me would like to volunteer and do it as a team. Tom if you can help us
out here then we would definitely appreciate it : )
We should get together and sync for gathering fixes and splitting up the tasks.
> On Dec 2, 2014, at 2:43 PM, Benjamin Mahler wrote:
>
> If anyone is interested i
Hey Tim C,
Out of curiosity, which GitHub issue are you referring to when you say "Apache
is one of the options mentioned"?
I don't see it it in the discussion thread for
https://github.com/coreos/rocket/issues/139, but I would love to find it
and +1 the idea. Moving to Apache would be great to s
Hi Dave,
I actually can't remember is it on the github issue, email list or twitter
feed, but definitely one of them.
Tim St Clair just brought up Apache on #139, and I'm a +1 on that as well.
Feel free to chime in on that Github issue you linked.
Tim
On Wed, Dec 3, 2014 at 11:40 AM, Dave Lest
Forgot to mention, unless you have a custom executor that you launch as a
docker container (by putting DockerInfo in the ExecutorInfo in your
TaskInfo), you can then re-use that executor for multiple tasks.
Tim
On Wed, Dec 3, 2014 at 11:47 AM, Tim Chen wrote:
> Hi Sharma,
>
> Yes currently dock
Hi Sharma,
Yes currently docker doesn't really support (out-of-box) launching multiple
processes in the same container. They just recently added docker exec but
not quite clear how it's best fit in mesos integration yet.
So each task run in the Docker containerizer has to be a seperate container
Thanks, I'll take the discussion to the GitHub issue.
On Wed, Dec 3, 2014 at 11:44 AM, Tim Chen wrote:
> Hi Dave,
>
> I actually can't remember is it on the github issue, email list or twitter
> feed, but definitely one of them.
>
> Tim St Clair just brought up Apache on #139, and I'm a +1 on th
Hi Connor,
Thanks for sharing the work you've been doing with Universe. Sounds
complimentary and pretty exciting! I thought I'd take a stab at making some
clarifications.
To rephrase your proposal by using a comparison, you're proposing the
"homebrew model" of package management here in terms of
I'd like to tag a question onto this; has anybody attempted to deploy spark
under Kubernetes
https://github.com/googlecloudplatform/kubernetes or Kubernetes mesos (
https://github.com/mesosphere/kubernetes-mesos ) .
On Wednesday, December 3, 2014, Matei Zaharia
wrote:
> I'd suggest asking about t
Hi Dick,
There is a PR on Spark to enable launching Spark executors with Docker
containers, and pending a committer to review and merge (
https://github.com/apache/spark/pull/3074)
If you like to try it out please take the patch and try it!
Tim
On Wed, Dec 3, 2014 at 6:31 PM, Kyle Ellrott wrot
Oh great, thanks Tim - I'll give that a whirl then.
A Spark rollout isn't in our immediate future, I'm just looking for a good
framework for compute alongside our marathon deployment. So a good
time to experiment!
On 4 December 2014 at 02:36, Tim Chen wrote:
> Hi Dick,
>
> There is a PR on Spark
23 matches
Mail list logo
