+1 (binding)
While it is of course sad to see things come to an end here, I do encourage
those of you who wish to see Mesos live on to try and breath new life into
it as a standalone project on github.
In that sense, this is more of a new beginning than an end.
The king is dead, long live the king
Hello old friends. Long time no hear.
+1 (binding)
Haven't written that in a while...
I also think moving it to the attic (as far as Apache is concerned) makes a
lot of sense.
It can have a life of its own on github (without the overhead of Apache
PMC, requirements for voting, etc.)
Kevin
Am D
The task exec and task attach work was completed in November of last
year. My guess is that it has never been compiled by default with a
release yet though. Can whoever is doing the 1.7 release check to make
sure that the new CLI is bundled, which includes these commands?
Am Fr., 28. Juni 2019 um
What you are describing is a feature we call 'admin tasks' or 'daemon
sets'.
Unfortunately, there is no direct support for these yet, but we do have
plans in the (relatively) near future to start working on it.
One of our use cases is exactly what you describe with the logging service.
On DC/OS w
Its probably worth linking this document here, which was started by some
guys at Nvidia and updated by ct.cl...@gmail.com
https://docs.google.com/document/d/1VR5hwcqkkFYM7I6qgZlA9y1qWJkkLLmL5plleiZa_ig/edit?disco=A5synUc
Kevin
On Tue, Feb 7, 2017 at 2:09 PM Benjamin Mahler wrote:
For GPUs
If you are running on standalone mesos+marathon, make sure you enable the
marathon flag for '--enable_features=gpu_resources' (and make sure you have
a version of marathon that supports this, i.e. 1.3). If you are on DC/OS,
then make sure you are running a very recent build (no version that's been
+user list
Hello all,
We recently started working on support for `docker attach` and `docker
exec` like functionality in Mesos.
Here is a link to the design doc:
https://docs.google.com/document/d/1nAVr0sSSpbDLrgUlAEB5hKzCl482NSVk8V0D56sFMzU
The design doc is not yet complete, but it is filled
As a side note. So long as you don't turn the cgroup devices isolator on,
there is nothing preventing your tasks from just accessing the GPU on the
host without actual allocation of the resource to anyone.
On Saturday, October 22, 2016, Kevin Klues wrote:
> Hi rodrick. There are no plan
Hi rodrick. There are no plans at the moment to support either fractional
GPU access or GPU memory allocation. The integration with the GPU drivers
and the Linux isolation methods just isn't there yet.
That said, in the upcoming 1.1 release, we have added support for 'Task
Groups' (a.k.a. Pods). S
Sorry, meant to send this to Haris directly. Please disregard.
On Wed, Oct 5, 2016 at 1:19 PM Kevin Klues wrote:
> Hey Haris,
>
> Now that the pods rush is over, we're finally ready to start pushing the
> CLI patches through. Will you have time in the next few weeks to work in
Hey Haris,
Now that the pods rush is over, we're finally ready to start pushing the
CLI patches through. Will you have time in the next few weeks to work in
any comments we have on them? If not, don't worry. I can take them over s d
make sure they get submitted with you as the author. Just need to
upport only support Mesos Containerizer but not
>> Docker Containerizer. There is a patch chain for Docker Containerizer GPU
>> support here: https://reviews.apache.org/r/50123/
>>
>> Thanks,
>>
>> Guangya
>>
>> On Tue, Aug 23, 2016 at 9:41 AM,
Hi Xinyu,
The problem you are seeing is that Mesos requires frameworks that want to
consume GPU resources to have the GPU_RESOURCES framework capability set.
Without this, the master will not send an offer to a framework if it
contains GPUs.
The choice to make frameworks explicitly opt-in to this
What is the GPU ID you are referring to?
The UUID of the GPU? The short ID listed by `nvidia-smi` when listing GPUs?
The minor number associated with the underlying /dev device (which may be
different than the number appearing at the end of /dev/nvidia*). Or do you
just care about the number on /d
It was committed. We just do rebases instead of merges, so sometimes
github gets confused as to whether it was actually merged or not. If you
click on the SHA in the description next to the notification it was closed
you can see that it was pushed back to master on apache/mesos.
On Thu, Jun 30, 2
https://reviews.apache.org/r/49456/
On Thu, Jun 30, 2016 at 8:55 AM Vinod Kone wrote:
> Mind updating
> https://github.com/apache/mesos/blob/master/docs/working-groups.md with
> this info?
>
> On Thu, Jun 30, 2016 at 8:44 AM, Kevin Klues wrote:
>
> > If you are inter
If you are interested in the ongoing GPU work on Mesos, please join the
#gpus channel at mesos.slack.com. The big announcements for the GPU work
will still happen on this mailing list, but the day to day discussions will
likely happen on the slack channel going forward.
https://docs.google.com/document/d/1r6Iv4Efu8v8IBrcUTjgYkvZ32WVscgYqrD07OyIglsA/edit?ts=57573bba#
On Wed, Jun 29, 2016 at 9:33 AM Kevin Klues wrote:
> Here is a link to the design doc again in case you missed it before. There
> is a section at the bottom describing what equivalent co
Here is a link to the design doc again in case you missed it before. There
is a section at the bottom describing what equivalent commands would look
like in the new design vs the old. Would it be a big burden to update your
scripts to use the new format for the commands or would you require strict
, purely from a number of volume statements), or it could be solved
> externally as the docker volume container does with a more generic solution.
>
> Thanks,
>
> JC
>
>> On Jun 20, 2016, at 6:59 PM, Kevin Klues wrote:
>>
>> For now we've decided to actuall
figuration/external information).
>
> Thanks,
>
> JC
>
>> On Jun 20, 2016, at 2:30 PM, Kevin Klues wrote:
>>
>> Sorry, the ticket just links to the nvidia-docker project without much
>> further explanation. The information at the link below should make it
>>
to required dependency though? Could you summarize?
>
>
> On Sun, Jun 19, 2016 at 12:33 PM, Kevin Klues wrote:
>>
>> Thanks Zhitao,
>>
>> I just pushed out a review for upgrades.md and added you as a reviewer.
>>
>> The new dependence was added in the
n,
>>
>> Thanks for letting us know. It seems like this is not called out in
>> upgrades.md, so can you please document this additional dependency there?
>>
>> Also, can you include the link to the JIRA or patch requiring this
>> dependency so we can have some con
hth,
> James
>
>
>
>
>
> On 06/18/2016 12:25 PM, Kevin Klues wrote:
>>
>> Hello all,
>>
>> Just an FYI that the newest libmesos now has an external dependence on
>> libelf on Linux. This dependence can be installed via the following
>> pac
Hello all,
Just an FYI that the newest libmesos now has an external dependence on
libelf on Linux. This dependence can be installed via the following
packages:
CentOS 6/7: yum install elfutils-libelf.x86_64
Ubuntu14.04: apt-get install libelf1
Alternatively you can install from source:
htt
There was some discussion of this between mpark and I in relation to
the v1 operator API. The idea was to have a base class for endpoints
that implement GET/POST/DELETE/PUT/etc... functions that return an
error by default. You can then override the specific subset of them
that that each endpoint s
As of last week, such a symlink has been added. The plan is to leave the
symlink in place until the deprecation cycle has ended. At that point, all
references to "slave" in our external APIs will be removed.
This email is just a warning that people should start migrating their
include paths over t
Hello all,
The 'external' containerizer has been deprecated since August and we
are now considering removing it permanently before the 0.29 release.
Are there any objections to this?
The following JIRA suggests that Hadoop on Mesos was still using the
External containerizer format.
https://issues
et past "Fix it, then ship it".
>>
>> Thanks,
>> Dan
>>
>>
>> -Original Message-
>> From: Kevin Klues [mailto:klue...@gmail.com]
>> Sent: Thursday, March 10, 2016 11:46 AM
>> To: user ; dev
>> Subject: Re: [VOTE] Relea
k has been landed in docker for
> quite a while and it is better to enable mesos docker containerizer support
> this.
>
> Thanks,
>
> Guangya
>
> On Thu, Mar 10, 2016 at 2:00 AM, Kevin Klues wrote:
>>
>> Tim,
>>
>> Is there a review other than t
1c
>>> https://reviews.apache.org/r/44468/
>>>
>>> Implemented runtime isolator default cmd test (still under review).
>>> https://reviews.apache.org/r/44469/
>>>
>>> Fixed a bug that causes the task stuck in staging state (still under
>>> review)
ache.org/r/44468/
Implemented runtime isolator default cmd test (still under review).
https://reviews.apache.org/r/44469/
Fixed a bug that causes the task stuck in staging state (still under review).
https://reviews.apache.org/r/44435/
On Tue, Mar 8, 2016 at 10:30 AM, Kevin Klues wrote:
> Yes, wi
Yes, will do.
On Tue, Mar 8, 2016 at 10:26 AM, Vinod Kone wrote:
> +kevin klues
>
> OK. I'm cancelling this vote since there are some show stopper issues that
> we need to cherry-pick. I'll cut another RC on Thursday.
>
> @shepherds: can you please make sure the blo
;
> On Tue, Mar 1, 2016 at 2:22 PM, Kevin Klues wrote:
>
> > The others all seem to have them though:
> >
> >
> >
> https://github.com/apache/mesos/commits/0.26.1-rc1/src/tests/master_tests.cpp
> >
> >
> https://github.com/apache/mesos/commits/0.2
I committed a fix for this in:
https://github.com/apache/mesos/commit/42f746937233349660c687ea7a66cc0a78871663
Looks like that's post 0.26 though, so maybe it should be included in the
.1 rc
On Mon, Feb 29, 2016 at 2:27 PM, Vinod Kone wrote:
> Looks like the ASF CI builds for CentOS7 are failin
n
>> MESOS-4518]
>
> This is supposed to be fixed in this release. It is concerning that this
> came up.
> Can you verify this and provide logs to Kevin Klues?
>
>
> —
> Joris Van Remoortere
> Mesosphere
>
> On Tue, Mar 1, 2016 at 2:00 PM, Michael Browning
> wrote:
://github.com/apache/mesos/commits/0.27.2-rc1/src/tests/master_tests.cpp
On Tue, Mar 1, 2016 at 2:17 PM, Kevin Klues wrote:
> Looks like this rc is missing this commit:
>
> https://github.com/apache/mesos/commit/d3108d776b6f7121e37176eda686ecc7245be4cd
>
> On Tue, Mar 1, 2016 at 2:0
Not that /state.json will be deprecated soon. Use /state instead.
On Tue, Jan 12, 2016 at 4:21 AM, Scott Rankin wrote:
> Got it. Thanks Qian, haosdent – I had been looking at
> /monitor/statistics.json on the slave, but not state.json.
>
> Scott
>
> From: Qian Zhang
> Reply-To: "user@mesos.apa
38 matches
Mail list logo
