[GitHub] mesos pull request #163: Update user-group.html.md to add Seville(Spain)

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/mesos/pull/163


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos issue #171: Update cli.py

[ronaldpetty]

Github user ronaldpetty commented on the issue:

https://github.com/apache/mesos/pull/171
  
Yes sir!  https://reviews.apache.org/r/52993/


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos issue #171: Update cli.py

[vinodkone]

Github user vinodkone commented on the issue:

https://github.com/apache/mesos/pull/171
  
Can you close this in favor of the review request?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos pull request #172: Update contributors.yaml

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/mesos/pull/172


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[VOTE] Release Apache Mesos 1.0.2 (rc1)

[Vinod Kone]

Hi all,


Please vote on releasing the following candidate as Apache Mesos 1.0.2.


1.0.2 includes the following:



** Bug


* [MESOS-5613] - mesos-local fails to start if MESOS_WORK_DIR isn't
set.

* [MESOS-6013] - Use readdir instead of readdir_r.


* [MESOS-6026] - Tasks mistakenly marked as FAILED due to race b/w
⁠sendExecutorTerminatedStatusUpdate()⁠ and 
⁠_statusUpdate()⁠

* [MESOS-6074] - Master check failure if the metrics endpoint is polled
soon after it starts

* [MESOS-6100] - Make fails compiling 1.0.1


* [MESOS-6104] - Potential FD double close in libevent's implementation
of `sendfile`.

* [MESOS-6118] - Agent would crash with docker container tasks due to
host mount table read.

* [MESOS-6122] - Mesos slave throws systemd errors even when passed a
flag to disable systemd

* [MESOS-6152] - Resource leak in libevent_ssl_socket.cpp.


* [MESOS-6216] - LibeventSSLSocketImpl::create is not safe to call
concurrently with os::getenv

* [MESOS-6233] - Master CHECK fails during recovery while relinking to
other masters

* [MESOS-6234] - Potential socket leak during Zookeeper network changes


* [MESOS-6245] - Driver based schedulers performing explicit
acknowledgements cannot acknowledge updates from HTTP based executors.

* [MESOS-6246] - Libprocess links will not generate an ExitedEvent if
the socket creation fails

* [MESOS-6269] - CNI isolator doesn't activate loopback interface


* [MESOS-6274] - Agent should not allow HTTP executors to re-subscribe
before containerizer recovery is done.

* [MESOS-6324] - CNI should not use `ifconfig` in executors
`pre_exec_command`

* [MESOS-6391] - Command task's sandbox should not be owned by root if
it uses container image.

* [MESOS-6393] - Deprecated SSL_ environment variables are non
functional already.




** Improvement


* [MESOS-6075] - Avoid libprocess functions in `mesos-containerizer
launch`.

* [MESOS-6299] - Master doesn't remove task from pending when it is
invalid




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=1.0.2-rc1




The candidate for Mesos 1.0.2 release is available at:

https://dist.apache.org/repos/dist/dev/mesos/1.0.2-rc1/mesos-1.0.2.tar.gz


The tag to be voted on is 1.0.2-rc1:

https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.2-rc1


The MD5 checksum of the tarball can be found at:

https://dist.apache.org/repos/dist/dev/mesos/1.0.2-rc1/mesos-1.0.2.tar.gz.md5


The signature of the tarball can be found at:

https://dist.apache.org/repos/dist/dev/mesos/1.0.2-rc1/mesos-1.0.2.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-1160


Please vote on releasing this package as Apache Mesos 1.0.2!


The vote is open until Fri Oct 21 14:49:04 PDT 2016 and passes if a
majority of at least 3 +1 PMC votes are cast.


[ ] +1 Release this package as Apache Mesos 1.0.2

[ ] -1 Do not release this package because ...


Thanks,

[GitHub] mesos pull request #172: Update contributors.yaml

[ronaldpetty]

GitHub user ronaldpetty opened a pull request:

https://github.com/apache/mesos/pull/172

Update contributors.yaml

Got my first PR in Mesos!

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ronaldpetty/mesos patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/172.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #172


commit 3a68f12aef4368db69bd15a8152cd095aa3cee65
Author: Ronald Petty 
Date:   2016-10-18T20:44:06Z

Update contributors.yaml

Got my first PR in Mesos!




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[VOTE] Release Apache Mesos 1.1.0 (rc1)

[Till Toenshoff]

Hi all,

Please vote on releasing the following candidate as Apache Mesos 1.1.0.


1.1.0 includes the following:

  * [MESOS-2449] - **Experimental** support for launching a group of tasks
via a new `LAUNCH_GROUP` Offer operation. Mesos will guarantee that either
all tasks or none of the tasks in the group are delivered to the executor.
Executors receive the task group via a new `LAUNCH_GROUP` event.

  * [MESOS-2533] - **Experimental** support for HTTP and HTTPS health checks.
Executors may now use the updated `HealthCheck` protobuf to implement
HTTP(S) health checks. Both default executors (command and docker) leverage
`curl` binary for sending HTTP(S) requests and connect to `127.0.0.1`,
hence a task must listen on all interfaces. On Linux, For BRIDGE and USER
modes, docker executor enters the task's network namespace.

  * [MESOS-3421] - **Experimental** Support sharing of resources across
containers. Currently persistent volumes are the only resources allowed to
be shared.

  * [MESOS-3567] - **Experimental** support for TCP health checks. Executors
may now use the updated `HealthCheck` protobuf to implement TCP health
checks. Both default executors (command and docker) connect to `127.0.0.1`,
hence a task must listen on all interfaces. On Linux, For BRIDGE and USER
modes, docker executor enters the task's network namespace.

  * [MESOS-4324] - Allow access to persistent volumes as read-only or read-write
by tasks. Mesos doesn't allow persistent volumes to be created as read-only
but in 1.1 it starts allow tasks to use the volumes as read-only. This is
mainly motivated by shared persistent volumes but applies to regular
persistent volumes as well.

  * [MESOS-5275] - **Experimental** support for linux capabilities. Frameworks
or operators now have fine-grained control over the capabilities that a
container may have. This allows a container to run as root, but not have all
the privileges associated with the root user (e.g., CAP_SYS_ADMIN).

  * [MESOS-5344] -- **Experimental** support for partition-aware Mesos
frameworks. In previous Mesos releases, when an agent is partitioned from
the master and then reregisters with the cluster, all tasks running on the
agent are terminated and the agent is shutdown. In Mesos 1.1, partitioned
agents will no longer be shutdown when they reregister with the master. By
default, tasks running on such agents will still be killed (for backward
compatibility); however, frameworks can opt-in to the new PARTITION_AWARE
capability. If they do this, their tasks will not be killed when a partition
is healed. This allows frameworks to define their own policies for how to
handle partitioned tasks. Enabling the PARTITION_AWARE capability also
introduces a new set of task states: TASK_UNREACHABLE, TASK_DROPPED,
TASK_GONE, TASK_GONE_BY_OPERATOR, and TASK_UNKNOWN. These new states are
intended to eventually replace the TASK_LOST state.

  * [MESOS-6077] - **Experimental** A new default executor is introduced which
frameworks can use to launch task groups as nested containers. All the
nested containers share resources likes cpu, memory, network and volumes.

  * [MESOS-6014] - **Experimental** A new port-mapper CNI plugin, the
`mesos-cni-port-mapper` has been introduced. For Mesos containers, with the
CNI port-mapper plugin, users can now expose container ports through host
ports using DNAT. This is especially useful when Mesos containers are
attached to isolated CNI networks such as private bridge networks, and the
services running in the container needs to be exposed outside these
isolated networks.


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=1.1.0-rc1


The candidate for Mesos 1.1.0 release is available at:
https://dist.apache.org/repos/dist/dev/mesos/1.1.0-rc1/mesos-1.1.0.tar.gz

The tag to be voted on is 1.1.0-rc1:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.1.0-rc1

The MD5 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.1.0-rc1/mesos-1.1.0.tar.gz.md5

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.1.0-rc1/mesos-1.1.0.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-1158

Please vote on releasing this package as Apache Mesos 1.1.0!

The vote is open until Fri Oct 21 21:57:02 CEST 2016 and passes if a majority 
of at least 3 +1 PMC votes are cast.

[ ] +1 Release this package as Apache Mesos 

[GitHub] mesos pull request #171: Update cli.py

[ronaldpetty]

GitHub user ronaldpetty opened a pull request:

https://github.com/apache/mesos/pull/171

Update cli.py

The CLI tools are failing per #MESOS-6409 in 1.0.1.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ronaldpetty/mesos master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/171.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #171


commit 3891871f256ddb75d4643253cd3cd75f97891e16
Author: Ronald Petty 
Date:   2016-10-18T17:11:59Z

Update cli.py

The CLI tools are failing per #MESOS-6409 in 1.0.1.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Non-checkpointing frameworks

[Neil Conway]

Hi folks,

Thanks for the feedback!

On Mon, Oct 17, 2016 at 12:44 PM, Zhitao Li  wrote:
> +1 to both A to B.
>
> Do we plan to eventually drop non-checkpionted framework support (possibly
> in v2) and declare that all frameworks has to operate in this assumption?

I think that's worth considering for v2, *if* we don't find anyone
that has good reasons for disabling checkpointing. But I'd expect it
is more likely we keep it around as an option that is disabled by
default.

Neil

Re: Separate Compilation of Tests

[Michael Park]

On Wed, Oct 5, 2016 at 9:22 AM, Joris Van Remoortere 
wrote:

> @mpark
> Can you clarify if your goal is to:
> 1) refactor the source code (maybe including things like cluster.hpp) so
> that general compilation of any file is faster. Examples include allowing
> non-header-only stout, splitting out some files, moving some more stuff to
> cpps.
> or 2) splitting out the files in the cmake / autoconf so that it's possible
> to compile a single test file?


In this thread I was trying to capture (2).

Although 2) is probably the easiest way to improved performance I was under
> the impression there were some arguments ~2 years ago around wanting to
> have all the tests in a single binary.
>

Mm... okay, I don't seem to recall :(


> I think any effort spent 1) will be valuable regardless. We've talked about
> a bunch of tasks in #1 and just needed time / commitment to them.
>

Yeah, I agree.

Some people have also suggested improved tooling. For example the gold
> linker.
>

@benjamin: I remember you were working on the gold linker stuff. As far as
I remember, it didn't get committed.
Are you interested in reviving that stuff?


> You should also see if you are ever IO bound. Debug builds generate
> binaries so large that you actually can become IO bound. There are ways to
> get around that too. There have been times where an optimized build has
> been faster than a debug build.
>

Yeah.. as far as I know optimized build builds faster. But I haven't
confirmed that.

Joris
>
> —
> *Joris Van Remoortere*
> Mesosphere
>
> On Tue, Sep 27, 2016 at 6:25 PM, Michael Park  wrote:
>
> > On Tue, Sep 27, 2016 at 12:21 PM, Alexander Rojas <
> alexan...@mesosphere.io
> > >
> > wrote:
> >
> > > The workaround I use is to go to the folder of the makefile root
> > > directory, so for
> > > Mesos, and then use the specific target, for example:
> > >
> > > For mesos-tests
> > > cd ${MESOS_SRC_ROOT}/build/src
> > > make -j4 mesos-tests && ./mesos-tests
> > >
> > > for libprocess
> > > cd ${MESOS_SRC_ROOT}/build/3rdparty/libprocess
> > > make -j4 libprocess-tests && ./libprocess-tests
> > >
> > > for stout
> > > cd ${MESOS_SRC_ROOT}/build/3rdparty/stout
> > > make -j4 stout-tests && ./stout-tests
> > >
> >
> > Alexander, I'm aware of these targets, and I guess my claim is that these
> > are not fine-grained enough.
> > Yes, I can work on a stout change and only run stout tests to iterate
> > without compiling/running all of the mesos tests.
> >
> > But I'm talking about times when I'm making mesos changes (let's say
> > involving a stout change),
> > I don't want to have to recompile basically all of the tests per
> iteration.
> >
> >
> > > I don’t think it would be hard to add top level targets that just do
> that
> > > from the top level.
> > >
> >
> > I imagine it's probably not either, but it's not what I'm looking for in
> > this thread.
> >
> > I however would like to have a target that compiles but not runs the
> tests.
> > >
> >
> > What do you mean by this? Are you looking for `make tests`?
> > As far as I'm aware, you can do `make tests`, and `make check` at every
> > level,
> > as opposed to the commands you're running to achieve what seems like the
> > same thing to me.
> >
> >
> > > > On 25 Sep 2016, at 15:56, Michael Park  wrote:
> > > >
> > > > Hello,
> > > >
> > > > I would like to propose a change in our build to help us improve
> > > developer
> > > > efficiency.
> > > > The proposal is to support separate compilation of unit tests.
> > > >
> > > > Currently, we have the old approach of invoking `make check -j N
> > > > GTEST_FILTER=""`, or a newer option of doing `make tests -j N`. From
> > what
> > > > I've heard the latter is slightly faster. However, when someone is
> > > > developing a specific feature, it's likely that they would like to
> make
> > > > changes and iterate on a single test file. In this workflow, having
> to
> > > > compile (virtually) __all__ of the tests is very burdensome. This
> > > situation
> > > > is not so bad if you're working in a very isolated part of the
> > codebase,
> > > > but it gets to be pretty bad if you're experimenting with parts that
> > are
> > > > widely used.
> > > >
> > > > An example of a workflow I'm aiming for would look something like:
> > > >
> > > >   1. write some code...
> > > >   2. `make check master_tests`  // compile and test
> > > >   `src/tests/master_tests.cpp`
> > > >   3. fix compilation errors...
> > > >   4. `make check master_tests`  // compile and test
> > > >   `src/tests/master_tests.cpp`
> > > >   5. change some stuff...
> > > >   6. `make check master_tests`  // compile and test
> > > >   `src/tests/master_tests.cpp`
> > > >   7. debug...
> > > >   8. `make check master_tests`  // compile and test
> > > >   `src/tests/master_tests.cpp`
> > > >   9. alright, looks good. `make check`
> > > >
> > > > I have 0 attachment to the `make check master_tests` syntax. It'll
> be a
> > > >