Hi folks,
Currently, the ownership of the persistent volumes are set to be the same
as the sandbox. In the implementation, we call `chown -R` on the persistent
volume to match that of the sandbox each time before we mount it into the
container.
Recently, we realized that this behavior is not idea
The goal is to let users leverage the nvidia Docker images
(https://hub.docker.com/r/nvidia/) without any added effort on their
behalf. Using docker they are able to launch containers from these
images by simply running `nvidia-docker run ...` (i.e. they are
unaware that a magic volume is being inj
>just type "y" and GitHub will redirect to the latest commit in master
Cool!
On Tue, Jun 21, 2016 at 10:12 AM, Erik Weathers
wrote:
> @Kevin:
>
> FYI, it's best practice to use a commit SHA in GitHub links so that future
> readers are seeing the content you intended.
>
> i.e., instead of:
>
>
@Kevin:
FYI, it's best practice to use a commit SHA in GitHub links so that future
readers are seeing the content you intended.
i.e., instead of:
-
https://github.com/NVIDIA/nvidia-docker/blob/master/tools/src/nvidia/volumes.go#L109
It's best to do:
-
https://github.com/NVIDIA/nv
For now we've decided to actually remove the hard dependence on libelf
for the 1.0 release and spend a bit more time thinking about the right
way to pull it in.
Jean, to answer your question though -- someone would still need to
consolidate these libraries, even if it wasn't left to Mesos to do so
+1 (binding) Internal CI build.
Here is a link to the deb/rpm packages:
http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-0.26.2-rc1
On Mon, Jun 20, 2016 at 6:07 PM, Vinod Kone wrote:
> +1 (binding)
>
> Tested on ASF CI w/ ubuntu. Note that centos:7 build issue is due to a
> known
+1 (binding)
Tested on ASF CI w/ ubuntu. Note that centos:7 build issue is due to a
known configuration issue (unable to find JAVA_HOME), fixed in 0.27.0, with
the build script.
*Revision*: 5edc7bab79649341c44df21c8842e05fb6d6c2bb
- refs/tags/0.26.2-rc1
Configuration Matrix gcc clang
centos:
Sorry, the ticket just links to the nvidia-docker project without much
further explanation. The information at the link below should make it
a bit more clear:
https://github.com/NVIDIA/nvidia-docker/wiki/NVIDIA-driver.
The crux of the issue is that we need to be able consolidate all of
the Nvidia
It's not immediately clear form the ticket why the change from optional
dependency 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 dep
Hi Robert,
I also think parallelization of fetching is important for many use cases to
reduce the time it takes to launch a task. Can we make sure the it's still
possible to parallel downloads if you file a feature request?
Also, when a task is launched, all URIs should be already fetched into
sa
Robert, I just checked the code and the ordering is not guaranteed since we
parallelize the download currently.
This sounds like a feature request. Robert, do you want to create a ticket?
For now, i think a startup script should be able to workaround that.
On Mon, Jun 20, 2016 at 11:02 AM, Robert
Zhitao,
Any environment variables generated by Mesos (i.e., MESOS_, LIBPROCESS_)
> will not be affected
Yes.
explicitly call this out in UPGRADES.md
Working on it.
- Jie
On Mon, Jun 20, 2016 at 11:43 AM, Zhitao Li wrote:
> Hi Jie,
>
> Can you confirm that your previous response of `Any e
Hi Jie,
Can you confirm that your previous response of `Any environment variables
generated by Mesos (i.e., MESOS_, LIBPROCESS_) will not be affected.` will
still be honored, or explicitly call this out in UPGRADES.md?
Thanks.
On Mon, Jun 20, 2016 at 11:39 AM, Jie Yu wrote:
> FYI, from Mesos 1
FYI, from Mesos 1.0, the executors will no longer inherit environment
variables from the agent by default. If you have environment environment
variables that you want to pass in to executors, please use `--
executor_environment_variables` flag on the agent.
commit ce4b3056164a804bea52810173dbd7a41
Looks like the master's event queue is filling up, although it's difficult
to tell what exactly is doing this. From the numbers in the gist, it's
evident that the master has seconds to minutes of backlog.
In general, there is very little processing cost associated per "accept".
The master does, h
Hi all,
Please vote on releasing the following candidate as Apache Mesos 0.26.2.
0.26.2 is a bug fix release. It includes the following:
[MESOS-4705] - Linux 'perf' parsing logic may fail when OS distribution has
pe
Jie, would it hurt if we would guarantee ordering of URIs? I could see use
cases where the order in which files are extracted matters. Protobuf preserves
ordering of repeated fields, so it shouldn't be a huge effort (it probably
already works).
Robert
> On Jun 17, 2016, at 7:37 PM, Jie Yu w
>
> For "That indicates a transition from the old systemd lack of support to
> the new support. "
> >> lack of what support ? would explain more details, and how to fix this?
> or may have other cause ?
There were a few versions of Mesos where we were not yet aware of some of
the issues with runn
18 matches
Mail list logo
