Re: [VOTE] Move Apache Mesos to Attic

[Kevin Klues]

+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!

Kevin

Am Di., 6. Apr. 2021 um 21:07 Uhr schrieb Benjamin Mahler <
bmah...@apache.org>:

> +1 (binding)
>
> Thanks to all who contributed to the project.
>
> On Mon, Apr 5, 2021 at 1:58 PM Vinod Kone  wrote:
>
>> Hi folks,
>>
>> Based on the recent conversations
>> <
>> https://lists.apache.org/thread.html/raed89cc5ab78531c48f56aa1989e1e7eb05f89a6941e38e9bc8803ff%40%3Cuser.mesos.apache.org%3E
>> >
>> on our mailing list, it seems to me that the majority consensus among the
>> existing PMC is to move the project to the attic <
>> https://attic.apache.org/>
>> and let the interested community members collaborate on a fork in Github.
>>
>> I would like to call a vote to dissolve the PMC and move the project to
>> the
>> attic.
>>
>> Please reply to this thread with your vote. Only binding votes from
>> PMC/committers count towards the final tally but everyone in the community
>> is encouraged to vote. See process here
>> .
>>
>> Thanks,
>>
>

-- 
~Kevin

Re: Next Steps

[Kevin Klues]

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 Do., 18. Feb. 2021 um 21:27 Uhr schrieb Till Toenshoff :

> +1 to what Renan (and Benjamin) suggested.
>
>

-- 
~Kevin

Re: Mesos task attach

[Kevin Klues]

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 22:10 Uhr schrieb Marc Roos :
>
>
> Will mesos task attach/exec become available in mesos (1.7)?
> http://mesos.apache.org/documentation/latest/cli/
>
>
>


-- 
~Kevin

Re: ensuring a particular task is deployed to "all" Mesos Worker hosts

[Kevin Klues]

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 we currently run our logging service as a systemd unit outside of
mesos since we can't guarantee it gets launched everywhere (the same is
true for a bunch of other services as well, namely metrics).

We don't have an exact timeline for when we will build this support yet,
but we will certainly announce it once we start actively working on it.


Erik Weathers  schrieb am Sa. 1. Juli 2017 um 09:45:

> That works for our particular use case, and is effectively what *we* do,
> but renders storm a "strange bird" amongst mesos frameworks.  Is there no
> trickery that could be played with mesos roles and/or reservations?
>
> - Erik
>
> On Sat, Jul 1, 2017 at 3:57 AM Dick Davies  wrote:
>
>> If it _needs_ to be there always then I'd roll it out with whatever
>> automation you use to deploy the mesos workers ; depending on
>> the scale you're running at launching it as a task is likely to be less
>> reliable due to outages etc.
>>
>> ( I understand the 'maybe all hosts' constraint but if it's 'up to one per
>> host', it sounds like a CM issue to me. )
>>
>> On 30 June 2017 at 23:58, Erik Weathers  wrote:
>> > hi Mesos folks!
>> >
>> > My team is largely responsible for maintaining the Storm-on-Mesos
>> framework.
>> > It suffers from a problem related to log retrieval:  Storm has a process
>> > called the "logviewer" that is assumed to exist on every host, and the
>> Storm
>> > UI provides links to contact this process to download logs (and other
>> > debugging artifacts).   Our team manually runs this process on each
>> Mesos
>> > host, but it would be nice to launch it automatically onto any Mesos
>> host
>> > where Storm work gets allocated. [0]
>> >
>> > I have read that Mesos has added support for Kubernetes-esque "pods" as
>> of
>> > version 1.1.0, but that feature seems somewhat insufficient for
>> implementing
>> > our desired behavior from my naive understanding.  Specifically, Storm
>> only
>> > has support for connecting to 1 logviewer per host, so unless pods can
>> have
>> > separate containers inside each pod [1], and also dynamically change
>> the set
>> > of executors and tasks inside of the pod [2], then I don't see how we'd
>> be
>> > able to use them.
>> >
>> > Is there any existing feature in Mesos that might help us accomplish our
>> > goal?  Or any upcoming features?
>> >
>> > Thanks!!
>> >
>> > - Erik
>> >
>> > [0] Thus the "all" in quotes in the subject of this email, because it
>> > *might* be all hosts, but it definitely would be all hosts where Storm
>> gets
>> > work assigned.
>> >
>> > [1] The Storm-on-Mesos framework leverages separate containers for each
>> > topology's Supervisor and Worker processes, to provide isolation between
>> > topologies.
>> >
>> > [2] The assignment of Storm Supervisors (a Mesos Executor) + Storm
>> Workers
>> > (a Mesos Task) onto hosts is ever changing in a given instance of a
>> > Storm-on-Mesos framework.  i.e., as topologies get launched and die, or
>> have
>> > their worker processes die, the processes are dynamically distributed
>> to the
>> > various Mesos Worker hosts.  So existing containers often have more
>> tasks
>> > assigned into them (thus growing their footprint) or removed from them
>> (thus
>> > shrinking the footprint).
>>
> --
~Kevin

Re: tag disks resources

[Kevin Klues]

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 there have been requests to expose the hardware and topology
information in a first class way, so that schedulers can consume it
consistently. Uses cases have been: handling heterogenous gpu hardware,
topology aware scheduling (critical for GPUs given NVLink vs PCI vs QPI
communication path between GPUs). CPUs and disk have had similar requests.

I filed https://issues.apache.org/jira/browse/MESOS-7080 to express the
need on the GPU side, feel free to file a ticket that captures the use
cases you have for disks.

On Wed, Feb 1, 2017 at 9:14 AM, Gabriel Hartmann 
wrote:

This request has been made many times.  Attributes on disks (or any
resource) doesn't yet exist.


On Wed, Feb 1, 2017 at 12:00 AM vincent gromakowski <
vincent.gromakow...@gmail.com> wrote:

It's OK for host selection but I am looking for a way to tag disks within
agents. One agent could have several class of disks...

Le 1 févr. 2017 5:28 AM, "tommy xiao"  a écrit :

search a more useful docs to you:
https://github.com/cantbewong/mesos-proposal-externalstorage/blob/master/Mesos%20Management%20of%20Persistent%20External%20Storage.md#use-of-attributes-to-indicate-connectable-storage-tuples-should-work-nicely-with-marathon



2017-02-01 12:26 GMT+08:00 tommy xiao :

the dis resource is tightly to host, so i think use constraint to filter
specified agent, then create your volume. does it match your meet?

2017-01-31 1:20 GMT+08:00 vincent gromakowski :

Hi,
Regarding the documentation, I can't find any way to tag some disks
resources but only to provide label to agents. My use case would be to
distinctly offer SSD and HDD based disks resources in a similar way as the
type of disk resource ("mount" or "path").
The classic approach would be to have a storage class attribute ?
Tx




-- 
Deshi Xiao
Twitter: xds2000
E-mail: xiaods(AT)gmail.com




-- 
Deshi Xiao
Twitter: xds2000
E-mail: xiaods(AT)gmail.com

Re: CUDA support makes slave receiving no jobs

[Kevin Klues]

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
released supports this yet), and follow the instructions at
https://github.com/dcos/dcos/pull/766

Cecile, Adam  schrieb am Di. 17. Jan. 2017 um 03:01:

> Hello,
>
>
> I just tried to enable CUDA support but when it's done the slave refuse to
> start anything (marathon job stuck in deploying state).
>
> If I replace isolation setting from
> "cgroups/cpu,cgroups/mem,cgroups/devices,gpu/nvidia" to
> "cgroups/cpu,cgroups/mem,cgroups/devices" jobs get started again.
>
>
> Of course, I couldn't not find anything useful in the log file (attached).
>
>
> Can someone have a look and let me know if there's something broken/badly
> configured/whatever ?
>
>
> Thanks in advance,
>
> ​
>
> Best regards, Adam.
>
>

Re: Mesos Container Attach/Exec

[Kevin Klues]

+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 out enough to start
eliciting feedback. Please feel free to add comments (or even add
suggestions for content!) as you wish.

Thanks!

Kevin

Re: Mesos CLI patches

[Kevin Klues]

Sorry, meant to send this to Haris directly. Please disregard.

On Wed, Oct 5, 2016 at 1:19 PM Kevin Klues <klue...@gmail.com> 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
> 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 know so
> we can plan accordingly. We want this stuff in fir the 1.1.0 release in 10
> days.
>
> Thanks!
>
> Kevin
>
>
> --
> ~Kevin
>

Re: Does Mesos 1.0 support GPU ?

[Kevin Klues]

Hey all, I finally got the GPU documentation published. Let me know if you
have any other questions. You can also ask in slack at #gpus.

https://github.com/apache/mesos/blob/master/docs/gpu-support.md

On Tue, Aug 23, 2016 at 7:15 AM Guangya Liu <gyliu...@gmail.com> wrote:

> You can only use GPU when you are using Mesos Containerizer, please take a
> look at what is the difference of Docker Containerizer and Mesos
> Containerizer from here
> https://github.com/apache/mesos/blob/master/docs/containerizer.md for
> detail.
>
> Thanks,
>
> Guangya
>
> On Tue, Aug 23, 2016 at 12:49 PM, <jef_c...@tsmc.com> wrote:
>
>> Hi Guangya,
>> Thanks for your information. does it mean that I could only managed GPU
>> resources through container based service ?
>>
>> Warm regards,
>>
>> Jef Chiu 邱征輝
>> TCCD/ICSD/IT
>> Taiwan Semiconductor Manufacturing Company
>>
>>
>>
>> |->
>> |Guangya Liu  |
>> |<gyliu...@gmail.com> |
>> | |
>> | |
>> | |
>> |2016/08/23 上午 10:49|
>> | |
>> | |
>> | |
>> |Please respond to|
>> |  user@mesos.apache.org  |
>> | |
>> |->
>>
>> >-|
>>   |
>>|
>>   |
>>|
>>   |
>>  To|
>>   |user@mesos.apache.org
>> |
>>   |
>>  cc|
>>   |jhch...@tsmc.com, seven_hs...@tsmc.com
>>|
>>   |
>> Subject|
>>   |Re: Does Mesos 1.0 support GPU ?
>>|
>>   |
>>|
>>   |
>>|
>>   |
>>|
>>   |
>>|
>>   |
>>|
>>
>> >-|
>>
>>
>>
>>
>> Just FYI, the current GPU support 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, David Greenberg <dsg123456...@gmail.com>
>> wrote:
>>   I've run the GPU support with the compiled packages from mesosphere.
>>   Here's a little demo repo that will set things up on an NVIDIA node on
>>   AWS: https://github.com/dgrnbrg/mesos-gpu-docker
>>
>>   Thanks to Kevin Klues for pointing me in the right direction!
>>
>>   On Mon, Aug 22, 2016 at 8:17 PM <jef_c...@tsmc.com> wrote:
>>Hi , yes, it seems that NV GPU already supported by Mesos 1.0. I am not
>>sure is there any difference between install Mesos 1.0 from RPM and
>>build
>>from source code . Should we build from source code when we need NV GPU
>>support feature in Mesos 1.0 ?
>>
>>Warm regards,
>>
>>Jef Chiu 邱征輝
>>TCCD/ICSD/IT
>>Taiwan Semiconductor Manufacturing Company
>>
>>
>>
>>|->
>>|Sam  |
>>|<usultra...@gmail.com>   |
>>| |
>>| |
>>| |
>>|2016/08/23 上午 08:51|
>>| |
&g

Re: Cannot receive GPU Mesos Agent resource offer

[Kevin Klues]

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 GPU_RESOURCES
capability was to keep legacy frameworks from accidentally consuming a
bunch of non-GPU resources on any GPU-capable machines in a cluster (and
thus blocking GPU jobs from running). It's not that big a deal if all of
your nodes have GPUs, but in a mixed-node environment, it can be a big
problem.

If you run your job with mesos-execute, you can add the flag
--framework_capabilities=GPU_RESOURCES to the command line.

If you wrote your own framework in C++, you can set it via something like:

  FrameworkInfo framework;
  framework.add_capabilities()->set_type(
FrameworkInfo::Capability::GPU_RESOURCES);

  GpuScheduler scheduler;

  driver = new MesosSchedulerDriver(
  ,
  framework,
  127.0.0.1:5050);

  driver->run();


If you launch your job via marathon, support exists in 1.3 release that
just came out yesterday. You can download it here:
https://github.com/mesosphere/marathon/releases/tag/v1.1.3

Hope this helps!

Kevin

Re: Retrieving Allocated GPU Resource ID for Task

[Kevin Klues]

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 /dev/nvidia* so that you can detect which
device you actually have access to on the file system?

Either way, there is no builtin support in mesos for getting any of these
values. However, you could easily run some script as a "pre-command" to get
at any of thees numbers.

For the UUID and short ID from `nvidia-smi`:
$ nvidia-smi -L

For the minor numbers:
$ nvidia-smi -q | grep Minor
Minor Number : 0
Minor Number : 1
Minor Number : 2
Minor Number : 3

For the actual /dev devices you have access to:
Loop through and call `touch` on each /dev/nvidia* device and see which
one's don't give you an error.

On Thu, Jun 30, 2016 at 2:47 PM Royce Cheng-Yue  wrote:

> Hi everyone,
>
> So far, I'm able to run a Mesos cluster with GPU resource allocation and
> can issue commands using mesos-execute; however, the commands I am planning
> to run require the allocated GPU resource IDs. Specifically, before our
> command executes, we need to set an environment variable which specifies
> the GPU ID to run the command on. Is there a way to retrieve the GPU ID
> after allocation and use the ID in our command before task execution?
>
> Thanks,
> Royce
>
> The information in this email is confidential and may be legally
> privileged. It is intended solely for the addressee. Access to this email
> by anyone else is unauthorized. If you are not the intended recipient, any
> disclosure, copying, distribution or any action taken or omitted to be
> taken in reliance on it, is prohibited and may be unlawful.
>

Re: Using Mesos?

[Kevin Klues]

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, 2016 at 2:11 PM Jay Taylor  wrote:

> I just tried this but it appears my PR was closed without comment.
>
> https://github.com/apache/mesos/pull/119
>
> What am I missing here? :)
>
> On Thu, Jun 30, 2016 at 1:45 PM, Benjamin Mahler 
> wrote:
>
>> Just a reminder. If you're using Mesos and want to be featured in our
>> list of users, send a PR to get your organization added:
>>
>> https://github.com/apache/mesos/blob/master/docs/powered-by-mesos.md
>>
>> If you've built a framework, and would like it featured in our list of
>> frameworks, send a PR to get your framework listed:
>>
>> https://github.com/apache/mesos/blob/master/docs/frameworks.md
>>
>> Thanks!
>>
>> Ben
>>
>
>

Re: GPU channel on slack

[Kevin Klues]

https://reviews.apache.org/r/49456/

On Thu, Jun 30, 2016 at 8:55 AM Vinod Kone <vinodk...@apache.org> 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 <klue...@gmail.com> wrote:
>
> > 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.
> >
>

GPU channel on slack

[Kevin Klues]

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.

Re: Mesos CLI

[Kevin Klues]

https://docs.google.com/document/d/1r6Iv4Efu8v8IBrcUTjgYkvZ32WVscgYqrD07OyIglsA/edit?ts=57573bba#

On Wed, Jun 29, 2016 at 9:33 AM Kevin Klues <klue...@gmail.com> 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 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
> backwards compatibility?
>
> Kevin
>
> On Wed, Jun 29, 2016 at 5:04 AM Tomas Barton <barton.to...@gmail.com>
> wrote:
>
>> Hi,
>>
>> we're using `mesos tail -f`, `mesos cat`, `mesos ps` quite a lot. It
>> would be nice if you keep those. Is there a document describing changes that
>> you're planning?
>>
>> just few ideas, it would be nice to have a command for:
>>   - listing all instances of a given task
>>   - join stderr and stdout (for stderr and stdout)
>>   - list failed tasks (or LOST, etc.)
>>   - grep task ID in `mesos ps`
>>
>> Regards,
>> Tomas
>>
>> On 17 June 2016 at 23:20, Haris Choudhary <hchoudh...@mesosphere.io>
>> wrote:
>>
>>> Thanks for the correction Jie!
>>> We will have a new cluster plugin that will still incorporate the
>>> features of these commands.
>>>
>>> On Fri, Jun 17, 2016 at 2:09 PM, Jie Yu <yujie@gmail.com> wrote:
>>>
>>>> Haris, i think you meant to make a backward incompatible change to the
>>>> existing commands, not removing them, right? For instance:
>>>>
>>>> mesos ps -> mesos cluster ps
>>>> mesos cat -> mesos cluster cat
>>>>
>>>> I guess the question is: is there anyone use those tools in production
>>>> and their tooling depends on those command.
>>>>
>>>> If not, it'll be much more easily for us to just make this backwards
>>>> incompatible change.
>>>>
>>>> June, Ben, can you let us know? Thanks!
>>>>
>>>> - Jie
>>>>
>>>> On Fri, Jun 17, 2016 at 1:57 PM, Ben Whaley <b...@whaletech.co> wrote:
>>>>
>>>>> We use mesos ps and would in fact love to see improvements to the CLI
>>>>> offerings, not reductions.
>>>>>
>>>>> Agreed. We use all the commands mentioned below.
>>>>>
>>>>> On Jun 17, 2016, at 1:03 PM, June Taylor <j...@umn.edu> wrote:
>>>>>
>>>>> We use mesos ps and would in fact love to see improvements to the CLI
>>>>> offerings, not reductions.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> June Taylor
>>>>> System Administrator, Minnesota Population Center
>>>>> University of Minnesota
>>>>>
>>>>> On Fri, Jun 17, 2016 at 12:11 PM, Haris Choudhary <
>>>>> hchoudh...@mesosphere.io> wrote:
>>>>>
>>>>>> Hey All,
>>>>>>
>>>>>> The Mesos CLI is going through a redesign. We are aware that the
>>>>>> "mesos-execute" command is used pretty often, so that will be ported into
>>>>>> the new CLI. However we're not sure if any of the other current CLI
>>>>>> commands are being used at all. The remaining list of commands are as
>>>>>> follow:
>>>>>> - cat
>>>>>> - ps
>>>>>> - tail
>>>>>> - scp
>>>>>>
>>>>>> If anyone is still using them, please let us know. *If a command is
>>>>>> not being used it may be removed completely without a deprecation 
>>>>>> notice. *
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>

Re: Mesos CLI

[Kevin Klues]

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
backwards compatibility?

Kevin

On Wed, Jun 29, 2016 at 5:04 AM Tomas Barton  wrote:

> Hi,
>
> we're using `mesos tail -f`, `mesos cat`, `mesos ps` quite a lot. It would
> be nice if you keep those. Is there a document describing changes that
> you're planning?
>
> just few ideas, it would be nice to have a command for:
>   - listing all instances of a given task
>   - join stderr and stdout (for stderr and stdout)
>   - list failed tasks (or LOST, etc.)
>   - grep task ID in `mesos ps`
>
> Regards,
> Tomas
>
> On 17 June 2016 at 23:20, Haris Choudhary 
> wrote:
>
>> Thanks for the correction Jie!
>> We will have a new cluster plugin that will still incorporate the
>> features of these commands.
>>
>> On Fri, Jun 17, 2016 at 2:09 PM, Jie Yu  wrote:
>>
>>> Haris, i think you meant to make a backward incompatible change to the
>>> existing commands, not removing them, right? For instance:
>>>
>>> mesos ps -> mesos cluster ps
>>> mesos cat -> mesos cluster cat
>>>
>>> I guess the question is: is there anyone use those tools in production
>>> and their tooling depends on those command.
>>>
>>> If not, it'll be much more easily for us to just make this backwards
>>> incompatible change.
>>>
>>> June, Ben, can you let us know? Thanks!
>>>
>>> - Jie
>>>
>>> On Fri, Jun 17, 2016 at 1:57 PM, Ben Whaley  wrote:
>>>
 We use mesos ps and would in fact love to see improvements to the CLI
 offerings, not reductions.

 Agreed. We use all the commands mentioned below.

 On Jun 17, 2016, at 1:03 PM, June Taylor  wrote:

 We use mesos ps and would in fact love to see improvements to the CLI
 offerings, not reductions.


 Thanks,
 June Taylor
 System Administrator, Minnesota Population Center
 University of Minnesota

 On Fri, Jun 17, 2016 at 12:11 PM, Haris Choudhary <
 hchoudh...@mesosphere.io> wrote:

> Hey All,
>
> The Mesos CLI is going through a redesign. We are aware that the
> "mesos-execute" command is used pretty often, so that will be ported into
> the new CLI. However we're not sure if any of the other current CLI
> commands are being used at all. The remaining list of commands are as
> follow:
> - cat
> - ps
> - tail
> - scp
>
> If anyone is still using them, please let us know. *If a command is
> not being used it may be removed completely without a deprecation notice. 
> *
>
> Thanks!
>


>>>
>>
>

Re: New external dependency

[Kevin Klues]

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 injected on their behalf). On
Mesos we want the experience to be similar.

In terms of providing an external component to do the library
consolidation instead of building it into Mesos itself -- we
considered this.  We originally planned on building this functionality
as an isolator module (giving us the benefit of external linkage
without having to run a separate linux process), but there some some
limitations with the current isolator interface that prohibit us from
doing this properly. Moreover, building it as an isolator module would
mean that it couldn't be shared by the docker containerizer (which we
plan to add support for in the future).

On Mon, Jun 20, 2016 at 7:30 PM, Jean Christophe “JC” Martin
<jch.mar...@gmail.com> wrote:
> Kevin,
>
> I agree about the need to create the volume, and gather the information. My 
> point was not really clear, sorry.
> My point was that it should not be different than any use case needing 
> special mounts and could either be solved by passing this information at the 
> time of container creation (it doesn’t seem that there are that many 
> libraries, and it would not be harder than say running the mesos slave in a 
> container, 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 <klue...@gmail.com> wrote:
>>
>> 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.
>> These libraries are spread across the file system, and need to be
>> pulled into a single place for easy injection. The full list of
>> binaries / libraries are here:
>>
>> https://github.com/NVIDIA/nvidia-docker/blob/master/tools/src/nvidia/volumes.go#L109
>>
>> We could put this burden on the operator and trust he gets it right,
>> or we could have Mesos programmatically do it itself. We considered
>> just leveraging the nvidia-docker-plugin itself (instead of
>> duplicating its functionality into mesos), but ultimately decided it
>> was better not to introduce an external dependency on it (since it is
>> a separate running excutable, rather than a simple library, like
>> libelf).
>>
>> On Mon, Jun 20, 2016 at 5:12 PM, Jean Christophe “JC” Martin
>> <jch.mar...@gmail.com> wrote:
>>> As an operator not using GPUs, I feel that the burden seems misplaced, and 
>>> disproportionate.
>>> I assume that the operator of a GPU cluster knows the location of the 
>>> libraries based on their OS, and could potentially provide this information 
>>> at the time of creating the containers. I am not sure to see why this 
>>> something that mesos is required to do (consolidating the libraries in the 
>>> volume, versus being a configuration/external information).
>>>
>>> Thanks,
>>>
>>> JC
>>>
>>>> On Jun 20, 2016, at 2:30 PM, Kevin Klues <klue...@gmail.com> wrote:
>>>>
>>>> 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 binaries/libraries into a single volume that we inject into
>>>> a docker container.  We use libelf is used to get the canonical names
>>>> of all the Nvidia libraries (i.e. SONAME in their dynamic sections) as
>>>> well as lookup what external dependences they have (i.e. NEEDED in
>>>> their dynamic sections) in order to build this volume.
>>>>
>>>> NOTE: None of this volume support is actually in Mesos yet -- we just
>>>> added the libelf dependence in anticipation of it.
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jun 20, 2016 at 12:59 PM, Yan Xu <xuj...@apple.com> wrote:
>>>>> It's not immediately clear form

Re: New external dependency

[Kevin Klues]

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.
These libraries are spread across the file system, and need to be
pulled into a single place for easy injection. The full list of
binaries / libraries are here:

https://github.com/NVIDIA/nvidia-docker/blob/master/tools/src/nvidia/volumes.go#L109

We could put this burden on the operator and trust he gets it right,
or we could have Mesos programmatically do it itself. We considered
just leveraging the nvidia-docker-plugin itself (instead of
duplicating its functionality into mesos), but ultimately decided it
was better not to introduce an external dependency on it (since it is
a separate running excutable, rather than a simple library, like
libelf).

On Mon, Jun 20, 2016 at 5:12 PM, Jean Christophe “JC” Martin
<jch.mar...@gmail.com> wrote:
> As an operator not using GPUs, I feel that the burden seems misplaced, and 
> disproportionate.
> I assume that the operator of a GPU cluster knows the location of the 
> libraries based on their OS, and could potentially provide this information 
> at the time of creating the containers. I am not sure to see why this 
> something that mesos is required to do (consolidating the libraries in the 
> volume, versus being a configuration/external information).
>
> Thanks,
>
> JC
>
>> On Jun 20, 2016, at 2:30 PM, Kevin Klues <klue...@gmail.com> wrote:
>>
>> 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 binaries/libraries into a single volume that we inject into
>> a docker container.  We use libelf is used to get the canonical names
>> of all the Nvidia libraries (i.e. SONAME in their dynamic sections) as
>> well as lookup what external dependences they have (i.e. NEEDED in
>> their dynamic sections) in order to build this volume.
>>
>> NOTE: None of this volume support is actually in Mesos yet -- we just
>> added the libelf dependence in anticipation of it.
>>
>>
>>
>>
>> On Mon, Jun 20, 2016 at 12:59 PM, Yan Xu <xuj...@apple.com> wrote:
>>> 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 <klue...@gmail.com> 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 JIRA that haosdent linked, but the
>>>> actual reason for adding the dependence is more related to:
>>>> https://issues.apache.org/jira/browse/MESOS-5401
>>>>
>>>> On Sun, Jun 19, 2016 at 9:34 AM, haosdent <haosd...@gmail.com> wrote:
>>>>> The related issue is Change build to always enable Nvidia GPU support
>>>>> for
>>>>> Linux
>>>>> Last time my local build break before Kevin send out the email, and then
>>>>> find this change.
>>>>>
>>>>> On Mon, Jun 20, 2016 at 12:11 AM, Zhitao Li <zhitaoli...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi Kevin,
>>>>>>
>>>>>> 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 contexts?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> On Sat, Jun 18, 2016 at 10:25 AM, Kevin Klues <klue...@gmail.com>
>>>>>> 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
>>>>>>> packages:
>>>>>>>
>>>>>>> C

Re: New external dependency

[Kevin Klues]

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 binaries/libraries into a single volume that we inject into
a docker container.  We use libelf is used to get the canonical names
of all the Nvidia libraries (i.e. SONAME in their dynamic sections) as
well as lookup what external dependences they have (i.e. NEEDED in
their dynamic sections) in order to build this volume.

NOTE: None of this volume support is actually in Mesos yet -- we just
added the libelf dependence in anticipation of it.




On Mon, Jun 20, 2016 at 12:59 PM, Yan Xu <xuj...@apple.com> wrote:
> 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 <klue...@gmail.com> 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 JIRA that haosdent linked, but the
>> actual reason for adding the dependence is more related to:
>> https://issues.apache.org/jira/browse/MESOS-5401
>>
>> On Sun, Jun 19, 2016 at 9:34 AM, haosdent <haosd...@gmail.com> wrote:
>> > The related issue is Change build to always enable Nvidia GPU support
>> > for
>> > Linux
>> > Last time my local build break before Kevin send out the email, and then
>> > find this change.
>> >
>> > On Mon, Jun 20, 2016 at 12:11 AM, Zhitao Li <zhitaoli...@gmail.com>
>> > wrote:
>> >>
>> >> Hi Kevin,
>> >>
>> >> 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 contexts?
>> >>
>> >> Thanks!
>> >>
>> >> On Sat, Jun 18, 2016 at 10:25 AM, Kevin Klues <klue...@gmail.com>
>> >> 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
>> >> > packages:
>> >> >
>> >> > CentOS 6/7: yum install elfutils-libelf.x86_64
>> >> > Ubuntu14.04:   apt-get install libelf1
>> >> >
>> >> > Alternatively you can install from source:
>> >> > https://directory.fsf.org/wiki/Libelf
>> >> >
>> >> > For developers, you will also need to install the libelf headers in
>> >> > order to build master. This dependency can be installed via:
>> >> >
>> >> > CentOS: elfutils-libelf-devel.x86_64
>> >> > Ubuntu: libelf-dev
>> >> >
>> >> > Alternatively, you can install from source:
>> >> > https://directory.fsf.org/wiki/Libelf
>> >> >
>> >> > The getting started guide and the support/docker_build.sh scripts
>> >> > have
>> >> > been updated appropriately, but you may need to update your local
>> >> > environment if you don't yet have these packages installed.
>> >> >
>> >> > --
>> >> > ~Kevin
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Cheers,
>> >>
>> >> Zhitao Li
>> >
>> >
>> >
>> >
>> > --
>> > Best Regards,
>> > Haosdent Huang
>>
>>
>>
>> --
>> ~Kevin
>
>



-- 
~Kevin

Re: New external dependency

[Kevin Klues]

Thanks Zhitao,

I just pushed out a review for upgrades.md and added you as a reviewer.

The new dependence was added in the JIRA that haosdent linked, but the
actual reason for adding the dependence is more related to:
https://issues.apache.org/jira/browse/MESOS-5401

On Sun, Jun 19, 2016 at 9:34 AM, haosdent <haosd...@gmail.com> wrote:
> The related issue is Change build to always enable Nvidia GPU support for
> Linux
> Last time my local build break before Kevin send out the email, and then
> find this change.
>
> On Mon, Jun 20, 2016 at 12:11 AM, Zhitao Li <zhitaoli...@gmail.com> wrote:
>>
>> Hi Kevin,
>>
>> 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 contexts?
>>
>> Thanks!
>>
>> On Sat, Jun 18, 2016 at 10:25 AM, Kevin Klues <klue...@gmail.com> 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
>> > packages:
>> >
>> > CentOS 6/7: yum install elfutils-libelf.x86_64
>> > Ubuntu14.04:   apt-get install libelf1
>> >
>> > Alternatively you can install from source:
>> > https://directory.fsf.org/wiki/Libelf
>> >
>> > For developers, you will also need to install the libelf headers in
>> > order to build master. This dependency can be installed via:
>> >
>> > CentOS: elfutils-libelf-devel.x86_64
>> > Ubuntu: libelf-dev
>> >
>> > Alternatively, you can install from source:
>> > https://directory.fsf.org/wiki/Libelf
>> >
>> > The getting started guide and the support/docker_build.sh scripts have
>> > been updated appropriately, but you may need to update your local
>> > environment if you don't yet have these packages installed.
>> >
>> > --
>> > ~Kevin
>> >
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>
>
>
>
> --
> Best Regards,
> Haosdent Huang



-- 
~Kevin

Re: New external dependency

[Kevin Klues]

Hi James,

A newer version should be OK. We only use a small subset of the
functions from libelf, and I believe they should all be backwards
compatible. If it becomes an issue, we could consider building our own
elf parser for the small subset of functionality that we need or
bundling a specific version of libelf with mesos itself. Let us know
if you run into any issues.

Kevin

On Sat, Jun 18, 2016 at 1:01 PM, james <gar...@verizon.net> wrote:
> Hello Kevin,
>
> On gentoo, I have this version::
>
> dev-libs/libelf-0.8.13-r2
>
> Which looks to be a bit newer, due to the rolling release updates
> of gentoo. It should not matter if a new version is used, right?
> Version 0.8.9 (stable) released on 22 August 2006, seem to be common among
> binary distros.
>
>
> Note, Version 0.8.12 and later work with some of the advanced Kernel
> performance tools..
>
> 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
>> packages:
>>
>> CentOS 6/7: yum install elfutils-libelf.x86_64
>> Ubuntu14.04:   apt-get install libelf1
>>
>> Alternatively you can install from source:
>> https://directory.fsf.org/wiki/Libelf
>>
>> For developers, you will also need to install the libelf headers in
>> order to build master. This dependency can be installed via:
>>
>> CentOS: elfutils-libelf-devel.x86_64
>> Ubuntu: libelf-dev
>>
>> Alternatively, you can install from source:
>> https://directory.fsf.org/wiki/Libelf
>>
>> The getting started guide and the support/docker_build.sh scripts have
>> been updated appropriately, but you may need to update your local
>> environment if you don't yet have these packages installed.
>>
>



-- 
~Kevin

New external dependency

[Kevin Klues]

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:
https://directory.fsf.org/wiki/Libelf

For developers, you will also need to install the libelf headers in
order to build master. This dependency can be installed via:

CentOS: elfutils-libelf-devel.x86_64
Ubuntu: libelf-dev

Alternatively, you can install from source:
https://directory.fsf.org/wiki/Libelf

The getting started guide and the support/docker_build.sh scripts have
been updated appropriately, but you may need to update your local
environment if you don't yet have these packages installed.

-- 
~Kevin

Re: Should "read-only" HTTP endpoints allow other request methods than "GET"?

[Kevin Klues]

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 supports.

On Tue, May 10, 2016 at 6:42 AM, Vinod Kone  wrote:
> +1 to only allow GET for read only
>
> @vinodkone
>
>> On May 10, 2016, at 6:37 AM, Jan Schlicht  wrote:
>>
>> Hi guys,
>>
>> while working on HTTP endpoint authorization for Mesos, I found some
>> interesting behavior: It's the responsibility of the HTTP endpoint handlers
>> to validate the HTTP request method they've been called with. Many
>> "read-only" endpoints (e.g. "/flags", "/state") don't do this at the
>> moment. This means that it's possible to send, for example, an HTTP "POST"
>> to the "/state" endpoint and get the same results as if it would have been
>> an HTTP "GET".
>> While this is currently not a problem, it will complicate things when we
>> want to authorize endpoint access. The authorization should take the HTTP
>> request method into account to distinguish between "user wants read access
>> to the endpoint" and "user wants write access to the endpoint". This makes
>> it ambitious on how to handle these "read-only" endpoints that also accept
>> a "POST" request.
>> The solution to that problem would be to add HTTP request method validation
>> to every endpoint, i.e. the read-only endpoints would reject any request
>> method that isn't "GET". I've created MESOS-5346 for that.
>> Because that would change the existing behavior, that allows to e.g. "POST"
>> to a "read-only" endpoint, I'd like to know if anybody relies on that
>> behavior, or if there are any other objections on changing it.
>>
>> Cheers,
>> Jan



-- 
~Kevin

Re: Rename 'include/mesos/slave' to 'include/mesos/agent'

[Kevin Klues]

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 to "agent" now to avoid complications in the future. For
now, both "slave" and "agent" will work, until the deprecation cycle ends
(I.e. a few months from now).

On Friday, April 29, 2016, zhiwei  wrote:

> Please use relative symlink path in further updates if any.
>
> Thanks.
>
> On Thu, Apr 28, 2016 at 2:06 PM, Zhou Z Xing  > wrote:
>
>>
>> Dear developers and users,
>>
>> While doing ticket MESOS-5230, we found that it is necessary to rename
>> folder 'include/mesos/slave' to 'include/mesos/agent'. With the change of
>> this folder, it may affect that:
>>
>>1. with command "make install", the header files installation location
>>will be changed to '$(DESTDIR)/include/mesos/agent'.
>>2. all the files that include the headers in this folder need to change
>>their include claim
>>3. for the protos that use 'mesos.slave' package need to change to use
>> '
>>mesos.agent' package
>>
>> As a result, if this change affects your program or environment, please
>> let
>> us know. We are planning this change soon, welcome your comments on this!
>>
>> Thanks & Best Wishes,
>>
>> Tom Xing(邢舟)
>> Emerging Technology Institute, IBM China Software Development Lab
>> --
>> IBM China Software Development Laboratory (CSDL)
>> Notes ID:Zhou Z Xing/China/IBM
>> Phone   :86-10-82450442
>> e-Mail  :xingz...@cn.ibm.com
>> 
>> Address :Building No.28, ZhongGuanCun Software Park, No.8 Dong Bei Wang
>> West Road, Haidian District, Beijing, P.R.China 100193
>> 地址:中国北京市海淀区东北旺西路8号 中关村软件园28号楼 100193
>>
>
>

-- 
~Kevin

Removing the External Containerizer

[Kevin Klues]

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.apache.org/jira/browse/MESOS-3370

However, it looks like this has been fixed in:
https://github.com/mesos/hadoop/pull/68

Is anyone else still using the external containerizer and would like
to see it persist a bit longer?

-- 
~Kevin

Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

[Kevin Klues]

The list of patches to include in 0.28.0-rc2 are now being tracked by a JIRA:

https://issues.apache.org/jira/browse/MESOS-4915

On Thu, Mar 10, 2016 at 3:51 PM, Vinod Kone <vinodk...@apache.org> wrote:
> I'll cut it first thing tomorrow. Whatever from kevin's list ablove gets in
> by tonight will get into rc2.
>
> On Thu, Mar 10, 2016 at 6:28 PM, Daniel Osborne <
> daniel.osbo...@metaswitch.com> wrote:
>
>> Kevin,
>>
>> When are you planning on cutting?
>>
>> I'm very keen to seeing 4370 get merged. It just needs some final fixes to
>> get 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 <user@mesos.apache.org>; dev <d...@mesos.apache.org>
>> Subject: Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)
>>
>> Updated list of patches to include in 0.28.0-rc2.  We are cutting the
>> release candidate today, so make sure your patches land soon if they
>> haven't already.
>>
>> Did I miss any?
>>
>> Committed:
>> Added documentation about container image support.
>> commit 7de8cdd4d8ed1d222fa03ea0d8fa6740c4a9f84b
>> https://reviews.apache.org/r/44414
>>
>> Fixed the logic for default docker cmd case.
>> commit e42f740ccb655c0478a3002c0b6fa90c1144f41c
>> https://reviews.apache.org/r/44468/
>>
>>
>> Still Under Review:
>> MESOS-4370 NetworkSettings.IPAddress field is deprectaed in Docker.
>> https://reviews.apache.org/r/43093/
>>
>> Fixed a bug that causes the task stuck in staging state.
>> https://reviews.apache.org/r/44435/
>>
>> Fixed http endpoint trigger two inverse offer calls.
>> https://reviews.apache.org/r/44258/
>>
>> Added support for "overlay" keyword.
>> https://reviews.apache.org/r/44421/
>>
>> Added document for overlayfs backend.
>> https://reviews.apache.org/r/44391/
>>
>> Add support for user-defined networks.
>> https://reviews.apache.org/r/42516/
>>
>> On Wed, Mar 9, 2016 at 5:50 PM, Guangya Liu <gyliu...@gmail.com> wrote:
>> > Tim,
>> >
>> > What about https://reviews.apache.org/r/42516/ for user-defined
>> > network in docker containerizer, the user defined network 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 <klue...@gmail.com> wrote:
>> >>
>> >> Tim,
>> >>
>> >> Is there a review other than the following for MESOS-4370?
>> >>
>> >> Restore Mesos' ability to extract Docker assigned IPs (still under
>> >> review):
>> >> https://reviews.apache.org/r/43093/
>> >>
>> >> If not, it was already on the list, but has not yet landed.
>> >>
>> >> On Wed, Mar 9, 2016 at 9:57 AM, Timothy Chen <tnac...@gmail.com> wrote:
>> >> > Also like to include MESOS-4370 as it fixes IP Address look up
>> >> > logic and also unblocks users using custom Docker network.
>> >> >
>> >> > Tim
>> >> >
>> >> > On Wed, Mar 9, 2016 at 9:55 AM, Gilbert Song
>> >> > <gilb...@mesosphere.io>
>> >> > wrote:
>> >> >> Hi Kevin,
>> >> >>
>> >> >> Please remove the the patch below from the list:
>> >> >> Implemented runtime isolator default cmd test (still under review).
>> >> >> https://reviews.apache.org/r/44469/
>> >> >>
>> >> >> Because the bug was fixed by patch #44468, the test should not be
>> >> >> considered as a block. I am updating MESOS-4888 and move the test
>> >> >> to a separate JIRA.
>> >> >>
>> >> >> Thanks,
>> >> >> Gilbert
>> >> >>
>> >> >> On Tue, Mar 8, 2016 at 2:43 PM, Kevin Klues <klue...@gmail.com>
>> wrote:
>> >> >>
>> >> >>> Here are the list of reviews/patches that have been called out in
>> >> >>> this thread for inclusion in 0.28.0-rc2.  Some of them are still
>> >> >>> under review and will need to land by Thursday to be included.
>> >> >>>
>> >> >>> Are there ot

Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

[Kevin Klues]

Updated list of patches to include in 0.28.0-rc2.  We are cutting the
release candidate today, so make sure your patches land soon if they
haven't already.

Did I miss any?

Committed:
Added documentation about container image support.
commit 7de8cdd4d8ed1d222fa03ea0d8fa6740c4a9f84b
https://reviews.apache.org/r/44414

Fixed the logic for default docker cmd case.
commit e42f740ccb655c0478a3002c0b6fa90c1144f41c
https://reviews.apache.org/r/44468/


Still Under Review:
MESOS-4370 NetworkSettings.IPAddress field is deprectaed in Docker.
https://reviews.apache.org/r/43093/

Fixed a bug that causes the task stuck in staging state.
https://reviews.apache.org/r/44435/

Fixed http endpoint trigger two inverse offer calls.
https://reviews.apache.org/r/44258/

Added support for "overlay" keyword.
https://reviews.apache.org/r/44421/

Added document for overlayfs backend.
https://reviews.apache.org/r/44391/

Add support for user-defined networks.
https://reviews.apache.org/r/42516/

On Wed, Mar 9, 2016 at 5:50 PM, Guangya Liu <gyliu...@gmail.com> wrote:
> Tim,
>
> What about https://reviews.apache.org/r/42516/ for user-defined network in
> docker containerizer, the user defined network 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 <klue...@gmail.com> wrote:
>>
>> Tim,
>>
>> Is there a review other than the following for MESOS-4370?
>>
>> Restore Mesos' ability to extract Docker assigned IPs (still under
>> review):
>> https://reviews.apache.org/r/43093/
>>
>> If not, it was already on the list, but has not yet landed.
>>
>> On Wed, Mar 9, 2016 at 9:57 AM, Timothy Chen <tnac...@gmail.com> wrote:
>> > Also like to include MESOS-4370 as it fixes IP Address look up logic
>> > and also unblocks users using custom Docker network.
>> >
>> > Tim
>> >
>> > On Wed, Mar 9, 2016 at 9:55 AM, Gilbert Song <gilb...@mesosphere.io>
>> > wrote:
>> >> Hi Kevin,
>> >>
>> >> Please remove the the patch below from the list:
>> >> Implemented runtime isolator default cmd test (still under review).
>> >> https://reviews.apache.org/r/44469/
>> >>
>> >> Because the bug was fixed by patch #44468, the test should not be
>> >> considered as a block. I am updating MESOS-4888 and move the test to a
>> >> separate JIRA.
>> >>
>> >> Thanks,
>> >> Gilbert
>> >>
>> >> On Tue, Mar 8, 2016 at 2:43 PM, Kevin Klues <klue...@gmail.com> wrote:
>> >>
>> >>> Here are the list of reviews/patches that have been called out in this
>> >>> thread for inclusion in 0.28.0-rc2.  Some of them are still under
>> >>> review and will need to land by Thursday to be included.
>> >>>
>> >>> Are there others?
>> >>>
>> >>> Jie's container image documentation (submitted):
>> >>> commit 7de8cdd4d8ed1d222fa03ea0d8fa6740c4a9f84b
>> >>> https://reviews.apache.org/r/44414
>> >>>
>> >>> Restore Mesos' ability to extract Docker assigned IPs (still under
>> >>> review):
>> >>> https://reviews.apache.org/r/43093/
>> >>>
>> >>> Fixed the logic for default docker cmd case (submitted).
>> >>> commit e42f740ccb655c0478a3002c0b6fa90c1144f41c
>> >>> 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).
>> >>> https://reviews.apache.org/r/44435/
>> >>>
>> >>> On Tue, Mar 8, 2016 at 10:30 AM, Kevin Klues <klue...@gmail.com>
>> >>> wrote:
>> >>> > Yes, will do.
>> >>> >
>> >>> > On Tue, Mar 8, 2016 at 10:26 AM, Vinod Kone <vinodk...@apache.org>
>> >>> 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 blocker tickets 

Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

[Kevin Klues]

Tim,

Is there a review other than the following for MESOS-4370?

Restore Mesos' ability to extract Docker assigned IPs (still under review):
https://reviews.apache.org/r/43093/

If not, it was already on the list, but has not yet landed.

On Wed, Mar 9, 2016 at 9:57 AM, Timothy Chen <tnac...@gmail.com> wrote:
> Also like to include MESOS-4370 as it fixes IP Address look up logic
> and also unblocks users using custom Docker network.
>
> Tim
>
> On Wed, Mar 9, 2016 at 9:55 AM, Gilbert Song <gilb...@mesosphere.io> wrote:
>> Hi Kevin,
>>
>> Please remove the the patch below from the list:
>> Implemented runtime isolator default cmd test (still under review).
>> https://reviews.apache.org/r/44469/
>>
>> Because the bug was fixed by patch #44468, the test should not be
>> considered as a block. I am updating MESOS-4888 and move the test to a
>> separate JIRA.
>>
>> Thanks,
>> Gilbert
>>
>> On Tue, Mar 8, 2016 at 2:43 PM, Kevin Klues <klue...@gmail.com> wrote:
>>
>>> Here are the list of reviews/patches that have been called out in this
>>> thread for inclusion in 0.28.0-rc2.  Some of them are still under
>>> review and will need to land by Thursday to be included.
>>>
>>> Are there others?
>>>
>>> Jie's container image documentation (submitted):
>>> commit 7de8cdd4d8ed1d222fa03ea0d8fa6740c4a9f84b
>>> https://reviews.apache.org/r/44414
>>>
>>> Restore Mesos' ability to extract Docker assigned IPs (still under review):
>>> https://reviews.apache.org/r/43093/
>>>
>>> Fixed the logic for default docker cmd case (submitted).
>>> commit e42f740ccb655c0478a3002c0b6fa90c1144f41c
>>> 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).
>>> https://reviews.apache.org/r/44435/
>>>
>>> On Tue, Mar 8, 2016 at 10:30 AM, Kevin Klues <klue...@gmail.com> wrote:
>>> > Yes, will do.
>>> >
>>> > On Tue, Mar 8, 2016 at 10:26 AM, Vinod Kone <vinodk...@apache.org>
>>> 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 blocker tickets are marked with
>>> >> fix version and that they land today or tomorrow?
>>> >>
>>> >> @kevin: since you have volunteered to help with the release, can you
>>> make
>>> >> sure we have a list of commits to cherry pick for rc2?
>>> >>
>>> >> Thanks,
>>> >>
>>> >>
>>> >> On Tue, Mar 8, 2016 at 12:05 AM, Shuai Lin <linshuai2...@gmail.com>
>>> wrote:
>>> >>
>>> >>> Maybe also https://issues.apache.org/jira/browse/MESOS-4877 and
>>> >>> https://issues.apache.org/jira/browse/MESOS-4878 ?
>>> >>>
>>> >>>
>>> >>> On Tue, Mar 8, 2016 at 9:13 AM, Jie Yu <yujie@gmail.com> wrote:
>>> >>>
>>> >>>> I'd like to fix https://issues.apache.org/jira/browse/MESOS-4888 as
>>> well
>>> >>>> if you guys plan to cut another RC
>>> >>>>
>>> >>>> On Mon, Mar 7, 2016 at 10:16 AM, Daniel Osborne <
>>> >>>> daniel.osbo...@metaswitch.com> wrote:
>>> >>>>
>>> >>>>> -1
>>> >>>>>
>>> >>>>> If it doesn’t cause too much pain, I'm hoping we can squeeze a
>>> >>>>> relatively small patch which restores Mesos' ability to extract
>>> Docker
>>> >>>>> assigned IPs. This has been broken with Docker 1.10's release over
>>> a month
>>> >>>>> ago, and prevents service discovery and DNS from working.
>>> >>>>>
>>> >>>>> Mesos-4370: https://issues.apache.org/jira/browse/MESOS-4370
>>> >>>>> RB# 43093: https://reviews.apache.org/r/43093/
>>> >>>>>
>>> >>>>> I've built 0.28.0-rc1 with this patch and can confirm that it fixes
>>> it
>>> >>>>> as expe

Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

[Kevin Klues]

Here are the list of reviews/patches that have been called out in this
thread for inclusion in 0.28.0-rc2.  Some of them are still under
review and will need to land by Thursday to be included.

Are there others?

Jie's container image documentation (submitted):
commit 7de8cdd4d8ed1d222fa03ea0d8fa6740c4a9f84b
https://reviews.apache.org/r/44414

Restore Mesos' ability to extract Docker assigned IPs (still under review):
https://reviews.apache.org/r/43093/

Fixed the logic for default docker cmd case (submitted).
commit e42f740ccb655c0478a3002c0b6fa90c1144f41c
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).
https://reviews.apache.org/r/44435/

On Tue, Mar 8, 2016 at 10:30 AM, Kevin Klues <klue...@gmail.com> wrote:
> Yes, will do.
>
> On Tue, Mar 8, 2016 at 10:26 AM, Vinod Kone <vinodk...@apache.org> 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 blocker tickets are marked with
>> fix version and that they land today or tomorrow?
>>
>> @kevin: since you have volunteered to help with the release, can you make
>> sure we have a list of commits to cherry pick for rc2?
>>
>> Thanks,
>>
>>
>> On Tue, Mar 8, 2016 at 12:05 AM, Shuai Lin <linshuai2...@gmail.com> wrote:
>>
>>> Maybe also https://issues.apache.org/jira/browse/MESOS-4877 and
>>> https://issues.apache.org/jira/browse/MESOS-4878 ?
>>>
>>>
>>> On Tue, Mar 8, 2016 at 9:13 AM, Jie Yu <yujie@gmail.com> wrote:
>>>
>>>> I'd like to fix https://issues.apache.org/jira/browse/MESOS-4888 as well
>>>> if you guys plan to cut another RC
>>>>
>>>> On Mon, Mar 7, 2016 at 10:16 AM, Daniel Osborne <
>>>> daniel.osbo...@metaswitch.com> wrote:
>>>>
>>>>> -1
>>>>>
>>>>> If it doesn’t cause too much pain, I'm hoping we can squeeze a
>>>>> relatively small patch which restores Mesos' ability to extract Docker
>>>>> assigned IPs. This has been broken with Docker 1.10's release over  a 
>>>>> month
>>>>> ago, and prevents service discovery and DNS from working.
>>>>>
>>>>> Mesos-4370: https://issues.apache.org/jira/browse/MESOS-4370
>>>>> RB# 43093: https://reviews.apache.org/r/43093/
>>>>>
>>>>> I've built 0.28.0-rc1 with this patch and can confirm that it fixes it
>>>>> as expected.
>>>>>
>>>>> Apologies for not bringing this to attention earlier.
>>>>>
>>>>> Thanks all,
>>>>> Dan
>>>>>
>>>>> -Original Message-
>>>>> From: Vinod Kone [mailto:vinodk...@apache.org]
>>>>> Sent: Thursday, March 3, 2016 5:44 PM
>>>>> To: dev <d...@mesos.apache.org>; user <user@mesos.apache.org>
>>>>> Subject: [VOTE] Release Apache Mesos 0.28.0 (rc1)
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>> Please vote on releasing the following candidate as Apache Mesos 0.28.0.
>>>>>
>>>>>
>>>>> 0.28.0 includes the following:
>>>>>
>>>>>
>>>>> 
>>>>>
>>>>>   * [MESOS-4343] - A new cgroups isolator for enabling the net_cls
>>>>> subsystem in
>>>>>
>>>>> Linux. The cgroups/net_cls isolator allows operators to provide
>>>>> network
>>>>>
>>>>>
>>>>> performance isolation and network segmentation for containers within
>>>>> a Mesos
>>>>>
>>>>> cluster. To enable the cgroups/net_cls isolator, append
>>>>> `cgroups/net_cls` to
>>>>>
>>>>> the `--isolation` flag when starting the slave. Please refer to
>>>>>
>>>>>
>>>>> docs/mesos-containerizer.md for more details.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   * [MESOS-4687] - The implementation of scalar resource values (e.g.,
>>>>> "2.5
>>&g

Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

[Kevin Klues]

Yes, will do.

On Tue, Mar 8, 2016 at 10:26 AM, Vinod Kone <vinodk...@apache.org> 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 blocker tickets are marked with
> fix version and that they land today or tomorrow?
>
> @kevin: since you have volunteered to help with the release, can you make
> sure we have a list of commits to cherry pick for rc2?
>
> Thanks,
>
>
> On Tue, Mar 8, 2016 at 12:05 AM, Shuai Lin <linshuai2...@gmail.com> wrote:
>
>> Maybe also https://issues.apache.org/jira/browse/MESOS-4877 and
>> https://issues.apache.org/jira/browse/MESOS-4878 ?
>>
>>
>> On Tue, Mar 8, 2016 at 9:13 AM, Jie Yu <yujie@gmail.com> wrote:
>>
>>> I'd like to fix https://issues.apache.org/jira/browse/MESOS-4888 as well
>>> if you guys plan to cut another RC
>>>
>>> On Mon, Mar 7, 2016 at 10:16 AM, Daniel Osborne <
>>> daniel.osbo...@metaswitch.com> wrote:
>>>
>>>> -1
>>>>
>>>> If it doesn’t cause too much pain, I'm hoping we can squeeze a
>>>> relatively small patch which restores Mesos' ability to extract Docker
>>>> assigned IPs. This has been broken with Docker 1.10's release over  a month
>>>> ago, and prevents service discovery and DNS from working.
>>>>
>>>> Mesos-4370: https://issues.apache.org/jira/browse/MESOS-4370
>>>> RB# 43093: https://reviews.apache.org/r/43093/
>>>>
>>>> I've built 0.28.0-rc1 with this patch and can confirm that it fixes it
>>>> as expected.
>>>>
>>>> Apologies for not bringing this to attention earlier.
>>>>
>>>> Thanks all,
>>>> Dan
>>>>
>>>> -Original Message-
>>>> From: Vinod Kone [mailto:vinodk...@apache.org]
>>>> Sent: Thursday, March 3, 2016 5:44 PM
>>>> To: dev <d...@mesos.apache.org>; user <user@mesos.apache.org>
>>>> Subject: [VOTE] Release Apache Mesos 0.28.0 (rc1)
>>>>
>>>> Hi all,
>>>>
>>>>
>>>> Please vote on releasing the following candidate as Apache Mesos 0.28.0.
>>>>
>>>>
>>>> 0.28.0 includes the following:
>>>>
>>>>
>>>> 
>>>>
>>>>   * [MESOS-4343] - A new cgroups isolator for enabling the net_cls
>>>> subsystem in
>>>>
>>>> Linux. The cgroups/net_cls isolator allows operators to provide
>>>> network
>>>>
>>>>
>>>> performance isolation and network segmentation for containers within
>>>> a Mesos
>>>>
>>>> cluster. To enable the cgroups/net_cls isolator, append
>>>> `cgroups/net_cls` to
>>>>
>>>> the `--isolation` flag when starting the slave. Please refer to
>>>>
>>>>
>>>> docs/mesos-containerizer.md for more details.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>   * [MESOS-4687] - The implementation of scalar resource values (e.g.,
>>>> "2.5
>>>>
>>>>
>>>> CPUs") has changed. Mesos now reliably supports resources with up to
>>>> three
>>>>
>>>> decimal digits of precision (e.g., "2.501 CPUs"); resources with
>>>> more than
>>>>
>>>> three decimal digits of precision will be rounded. Internally,
>>>> resource math
>>>>
>>>> is now done using a fixed-point format that supports three decimal
>>>> digits of
>>>>
>>>> precision, and then converted to/from floating point for input and
>>>> output,
>>>>
>>>> respectively. Frameworks that do their own resource math and
>>>> manipulate
>>>>
>>>>
>>>> fractional resources may observe differences in roundoff error and
>>>> numerical
>>>>
>>>> precision.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>   * [MESOS-4479] - Reserved resources can now optionally include
>>>> "labels".
>>>>
>>>>
>>>> Labels are a set of key-value pairs that can be used

Re: [VOTE] Release Apache Mesos 0.27.2 (rc1)

[Kevin Klues]

-1 (non-binding)

This release
​candidate ​
should have included the backport to re
​s​
olv
​e ​
MESOS-4518 <https://issues.apache.org/jira/browse/MESOS-4518>​.
​All ​of the other release candidates that came out as backports recently
have included this, but somehow this one was overlooked.




On Tue, Mar 1, 2016 at 4:35 PM, Greg Mann <g...@mesosphere.io> wrote:

> I was able to successfully test a simple upgrade scenario between
> 0.26.1-rc1 and 0.27.2-rc1 using Niklas's upgrade testing script, which I've
> modified slightly and reposted here: https://reviews.apache.org/r/44229/
>
> On Tue, Mar 1, 2016 at 2:22 PM, Kevin Klues <klue...@gmail.com> 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.25.1-rc1/src/tests/master_tests.cpp
> >
> >
> https://github.com/apache/mesos/commits/0.24.2-rc1/src/tests/master_tests.cpp
> >
> > Just not:
> >
> >
> https://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 <klue...@gmail.com> wrote:
> > > Looks like this rc is missing this commit:
> > >
> > >
> >
> https://github.com/apache/mesos/commit/d3108d776b6f7121e37176eda686ecc7245be4cd
> > >
> > > On Tue, Mar 1, 2016 at 2:08 PM, Joris Van Remoortere
> > > <jo...@mesosphere.io> wrote:
> > >> @Michael Browning:
> > >>>
> > >>> MasterTest.MaxCompletedTasksPerFrameworkFlag [flaky, tracked in
> > >>> 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 <
> > invitapri...@gmail.com>
> > >> wrote:
> > >>>
> > >>> +1 (non-binding)
> > >>>
> > >>> Fedora 23: `make check` non-root OK
> > >>> OS X: `make check` non-root OK
> > >>> Ubuntu 14.04: `make check` non-root, three failures:
> > >>> ContainerLoggerTest.DefaultToSandbox [flaky, tracked in MESOS-4615]
> > >>> MasterQuotaTest.AvailableResourcesAfterRescinding [flaky, tracked in
> > >>> MESOS-4542]
> > >>> MasterTest.MaxCompletedTasksPerFrameworkFlag [flaky, tracked in
> > >>> MESOS-4518]
> > >>>
> > >>> On Mon, Feb 29, 2016 at 10:40 PM, Greg Mann <g...@mesosphere.io>
> > wrote:
> > >>>
> > >>> > +1 (non-binding)
> > >>> >
> > >>> > `sudo make check` on Ubuntu 14.04 using gcc, with libevent and SSL
> > >>> > enabled.
> > >>> >
> > >>> > All tests pass except
> > MemoryPressureMesosTest.CGROUPS_ROOT_Statistics,
> > >>> > which seems to be due to the issue found here:
> > >>> > https://issues.apache.org/jira/browse/MESOS-4053
> > >>> >
> > >>> >
> > >>> > On Mon, Feb 29, 2016 at 2:17 PM, Michael Park <mp...@apache.org>
> > wrote:
> > >>> >
> > >>> > > Vinod, we've only committed the CHANGELOGs to the specific tags.
> I
> > >>> > > didn't
> > >>> > > realize that I should commit those to master as well, but it
> makes
> > >>> > > total
> > >>> > > sense to do so. I'll do that. Thanks.
> > >>> > >
> > >>> > > On 29 February 2016 at 13:50, Vinod Kone <vinodk...@apache.org>
> > wrote:
> > >>> > >
> > >>> > >> I don't see CHANGELOGs for these versions on the master branch?
> > >>> > >>
> > >>> > >> On Mon, Feb 29, 2016 at 1:39 PM, Neil Conway <
> > neil.con...@gmail.com>
> > >>> > >> wrote:
> > >>> > >>
> > >>> > >> > As described (briefly) in the release emails, 0.27.2, 0.26.1,
> > >>> > >> > 0.25.1,
> > >>> > >> > and 0.24.2 contains a new feature: "reliable floating point
> for
> > >>> > >> > scalar
> > >

Re: [VOTE] Release Apache Mesos 0.26.1 (rc1)

[Kevin Klues]

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 failing because they are
> unable to find JAVA_HOME. Couldn't tell if it's an issue with the docker
> build script or something in the configure script.
>
>
> checking for svn_txdelta in -lsvn_delta-1... yes
> checking for sasl_done in -lsasl2... yes
> checking SASL CRAM-MD5 support... yes
> checking for javac... /usr/bin/javac
> checking for java... /usr/bin/java
> checking value of Java system property 'java.home'... 
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.71-2.b15.el7_2.x86_64/jre
> configure: error: could not guess JAVA_HOME
>
>
>
> *Revision*: a05261dbed1c2577676b11235380de95d586aeeb
>
>- refs/tags/0.26.1-rc1
>
> Configuration Matrix gcc clang
> centos:7 --verbose --enable-libevent --enable-ssl
> [image: Failed]
> 
> [image: Not run]
> --verbose
> [image: Failed]
> 
> [image: Not run]
> ubuntu:14.04 --verbose --enable-libevent --enable-ssl
> [image: Success]
> 
> [image: Success]
> 
> --verbose
> [image: Success]
> 
> [image: Success]
> 
>
> On Mon, Feb 29, 2016 at 11:21 AM, Kapil Arya  wrote:
>
>> +1 (binding)
>>
>> Successful CI builds for the following distros:
>>
>> amd64/centos/6
>> amd64/centos/7
>> amd64/debian/jessie
>> amd64/ubuntu/precise
>> amd64/ubuntu/trusty
>> amd64/ubuntu/vivid
>>
>> Kapil
>>
>> On Sat, Feb 27, 2016 at 12:26 AM, Michael Park  wrote:
>>
>> > Hi all,
>> >
>> > Please vote on releasing the following candidate as Apache Mesos 0.26.1.
>> >
>> >
>> > 0.26.1 includes the following:
>> >
>> >
>> 
>> >
>> >- Improvements
>> >   - `/state` endpoint performance
>> >   - systemd integration
>> >   - GLOG performance
>> >   - Configurable task/framework history
>> >   - Offer filter timeout fix for backlogged allocator
>> >
>> >
>> >- Bugs
>> >- SSL
>> >   - Libevent
>> >   - Fixed point resources math
>> >- HDFS
>> >   - Agent upgrade compatibility
>> >
>> > The CHANGELOG for the release is available at:
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.26.1-rc1
>> >
>> >
>> 
>> >
>> > The candidate for Mesos 0.26.1 release is available at:
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/0.26.1-rc1/mesos-0.26.1.tar.gz
>> >
>> > The tag to be voted on is 0.26.1-rc1:
>> >
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.26.1-rc1
>> >
>> > The MD5 checksum of the tarball can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/0.26.1-rc1/mesos-0.26.1.tar.gz.md5
>> >
>> > The signature of the tarball can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/0.26.1-rc1/mesos-0.26.1.tar.gz.asc
>> >
>> > The PGP key used to sign the release is here:
>> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>> >
>> > The JAR is up in Maven in a staging repository here:
>> > https://repository.apache.org/content/repositories/orgapachemesos-1106
>> >
>> > Please vote on releasing this package as Apache Mesos 0.26.1!
>> >
>> > The vote is open until Wed Mar 2 23:59:59 PST 2016 and passes if a
>> majority
>> > of at least 3 +1 PMC votes are cast.
>> >
>> > [ ] +1 Release this package as Apache Mesos 0.26.1
>> > [ ] -1 Do not release this package because ...
>> >
>> > Thanks,
>> >
>> > Joris, Kapil, MPark
>> >
>>
>
>


-- 
~Kevin

Re: [VOTE] Release Apache Mesos 0.27.2 (rc1)

[Kevin Klues]

Looks like this rc is missing this commit:

https://github.com/apache/mesos/commit/d3108d776b6f7121e37176eda686ecc7245be4cd

On Tue, Mar 1, 2016 at 2:08 PM, Joris Van Remoortere
<jo...@mesosphere.io> wrote:
> @Michael Browning:
>>
>> MasterTest.MaxCompletedTasksPerFrameworkFlag [flaky, tracked in
>> 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 <invitapri...@gmail.com>
> wrote:
>>
>> +1 (non-binding)
>>
>> Fedora 23: `make check` non-root OK
>> OS X: `make check` non-root OK
>> Ubuntu 14.04: `make check` non-root, three failures:
>> ContainerLoggerTest.DefaultToSandbox [flaky, tracked in MESOS-4615]
>> MasterQuotaTest.AvailableResourcesAfterRescinding [flaky, tracked in
>> MESOS-4542]
>> MasterTest.MaxCompletedTasksPerFrameworkFlag [flaky, tracked in
>> MESOS-4518]
>>
>> On Mon, Feb 29, 2016 at 10:40 PM, Greg Mann <g...@mesosphere.io> wrote:
>>
>> > +1 (non-binding)
>> >
>> > `sudo make check` on Ubuntu 14.04 using gcc, with libevent and SSL
>> > enabled.
>> >
>> > All tests pass except MemoryPressureMesosTest.CGROUPS_ROOT_Statistics,
>> > which seems to be due to the issue found here:
>> > https://issues.apache.org/jira/browse/MESOS-4053
>> >
>> >
>> > On Mon, Feb 29, 2016 at 2:17 PM, Michael Park <mp...@apache.org> wrote:
>> >
>> > > Vinod, we've only committed the CHANGELOGs to the specific tags. I
>> > > didn't
>> > > realize that I should commit those to master as well, but it makes
>> > > total
>> > > sense to do so. I'll do that. Thanks.
>> > >
>> > > On 29 February 2016 at 13:50, Vinod Kone <vinodk...@apache.org> wrote:
>> > >
>> > >> I don't see CHANGELOGs for these versions on the master branch?
>> > >>
>> > >> On Mon, Feb 29, 2016 at 1:39 PM, Neil Conway <neil.con...@gmail.com>
>> > >> wrote:
>> > >>
>> > >> > As described (briefly) in the release emails, 0.27.2, 0.26.1,
>> > >> > 0.25.1,
>> > >> > and 0.24.2 contains a new feature: "reliable floating point for
>> > >> > scalar
>> > >> > resources" (MESOS-4687).
>> > >> >
>> > >> > To elaborate on that slightly, Mesos now only supports scalar
>> > >> > resource
>> > >> > values with three decimal digits of precision (e.g., reserving
>> > >> > "5.001
>> > >> > CPUs" for a task). As a result of this change, frameworks that do
>> > >> > their own resource math may see slightly different results;
>> > >> > furthermore, if any frameworks were trying to manage extremely
>> > >> > fine-grained resource values (> 3 decimal digits of precision),
>> > >> > that
>> > >> > will no longer be supported.
>> > >> >
>> > >> > For more information, please see:
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> >
>> > https://mail-archives.apache.org/mod_mbox/mesos-user/201602.mbox/%3CCAOW5sYZJn5caBOwZyPV008JgL1F2FYFxL_bM5CtYA2PF2OG7Bw%40mail.gmail.com%3E
>> > >> >
>> > >> >
>> > >>
>> >
>> > https://docs.google.com/document/d/14qLxjZsfIpfynbx0USLJR0GELSq8hdZJUWw6kaY_DXc/edit?usp=sharing
>> > >> > https://issues.apache.org/jira/browse/MESOS-4687
>> > >> >
>> > >> > Neil
>> > >> >
>> > >> >
>> > >> > On Fri, Feb 26, 2016 at 8:54 PM, Michael Park <mcyp...@gmail.com>
>> > >> wrote:
>> > >> > > Hi all,
>> > >> > >
>> > >> > > Please vote on releasing the following candidate as Apache Mesos
>> > >> 0.27.2.
>> > >> > >
>> > >> > >
>> > >> > > 0.27.2 includes the following:
>> > >> > >
>> > >> >
>> > >>
>> >
>> > 
>> > >> > >
>> > >> > > MESOS-4693 - Variable