Re: 0.28.3 release dashboard!

[Joseph Wu]

Thanks for the suggestions Benjamin!

I've re-purposed one of the dashboard queries to track "Issues affecting
0.28.x that are resolved in versions later than 0.28".
https://issues.apache.org/jira/issues/?filter=12338701
^ That will show up on the dashboard too.

There are 26 issues in that list, which we'll triage.  I suspect most of
these will not be backported if they aren't already.

On Mon, Nov 7, 2016 at 5:31 AM, Benjamin Bannier <
benjamin.bann...@mesosphere.io> wrote:

> Hi Joseph and Anand,
>
> > We are planning to cut this patch release within three workdays - that
> would be around Monday next week. So, if you have any patches that need to
> get into 0.28.3 make sure that either it is already in the 0.28.x branch or
> the corresponding ticket has a target version set to 0.28.3.
>
> There are still a number of rather unpleasant issues filed against 0.28
> which are only fixed in versions > 0.28.3.
>
>   https://issues.apache.org/jira/browse/MESOS-5224
>   https://issues.apache.org/jira/browse/MESOS-5685
>   https://issues.apache.org/jira/browse/MESOS-5727
>   https://issues.apache.org/jira/browse/MESOS-5763
>   https://issues.apache.org/jira/browse/MESOS-6391
>
> Maybe it would be worthwhile to backport some of these.
>
> FYI, I used the following query which still required some manual filtering:
>
> project = Mesos AND \
> affectedVersion in (0.28, 0.28.0, 0.28.1, 0.28.2, 0.28.3) AND \
> (fixVersion not in (0.28.3) OR fixVersion < 0.28.3) AND \
> status = Resolved and type = Bug
>
> This might to be like a worthwhile addition to patch release dashboards
> (if somebody with more JIRA foo could come up with an actually working
> query).
>
>
> Cheers,
>
> Benjamin

Re: [VOTE] Release Apache Mesos 1.1.0 (rc3)

[Vinod Kone]

+1 (binding)

Tested on ASF CI.

*Revision*: a44b077ea0df54b77f05550979e1e97f39b15873

   - refs/tags/1.1.0-rc3

Configuration Matrix gcc clang
centos:7 --verbose --enable-libevent --enable-ssl autotools
[image: Success]

[image: Not run]
cmake
[image: Success]

[image: Not run]
--verbose autotools
[image: Success]

[image: Not run]
cmake
[image: Success]

[image: Not run]
ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
[image: Success]

[image: Success]

cmake
[image: Success]

[image: Success]

--verbose autotools
[image: Success]

[image: Success]

cmake
[image: Success]

[image: Success]


On Mon, Nov 7, 2016 at 7:49 AM, Evers Benno  wrote:

> +1 (non-binding)
>
> Built and installed on Ubuntu 10.04 + 14.04
>
> Configured with --disable-java --enable-python --disable-bundled-pip
> --disable-python-dependency-install
>
> On 04.11.2016 14:15, Till Toenshoff wrote:
> > 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 

[VOTE] Release Apache Mesos 1.0.2 (rc3)

[Vinod Kone]

Hi all,


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


This is a bug fix release.


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-rc3




The candidate for Mesos 1.0.2 release is available at:

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


The tag to be voted on is 1.0.2-rc3:

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


The MD5 checksum of the tarball can be found at:

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


Please vote on releasing this package as Apache Mesos 1.0.2!


The vote is open until Thu Nov 10 11:22:30 PST 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,

Re: [VOTE] Release Apache Mesos 1.1.0 (rc3)

[Evers Benno]

+1 (non-binding)

Built and installed on Ubuntu 10.04 + 14.04

Configured with --disable-java --enable-python --disable-bundled-pip
--disable-python-dependency-install

On 04.11.2016 14:15, Till Toenshoff wrote:
> 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 tasks to access persistent volumes in either a
> read-only or read-write manner. Using a volume in read-only mode can
> simplify sharing that volume between multiple tasks on the same agent.
> 
>   * [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-5788] - **Experimental** support for Java scheduler adapter. This
> adapter allows framework developers to toggle between the old/new API
> (driver/scheduler library) implementations, thereby allowing them to 
> easily
> transition their frameworks to the new v1 Scheduler API.
> 
>   * [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.
> 
>   * [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.
> 
> 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-rc3
> 
> 
> The candidate for Mesos 1.1.0 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/1.1.0-rc3/mesos-1.1.0.tar.gz
> 
> The tag to be voted on is 1.1.0-rc3:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.1.0-rc3
> 
> The MD5 checksum of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/1.1.0-rc3/mesos-1.1.0.tar.gz.md5
> 
> The 

Re: 0.28.3 release dashboard!

[Benjamin Bannier]

Hi Joseph and Anand,

> We are planning to cut this patch release within three workdays - that would 
> be around Monday next week. So, if you have any patches that need to get into 
> 0.28.3 make sure that either it is already in the 0.28.x branch or the 
> corresponding ticket has a target version set to 0.28.3.

There are still a number of rather unpleasant issues filed against 0.28 which 
are only fixed in versions > 0.28.3.

  https://issues.apache.org/jira/browse/MESOS-5224
  https://issues.apache.org/jira/browse/MESOS-5685
  https://issues.apache.org/jira/browse/MESOS-5727
  https://issues.apache.org/jira/browse/MESOS-5763
  https://issues.apache.org/jira/browse/MESOS-6391

Maybe it would be worthwhile to backport some of these.

FYI, I used the following query which still required some manual filtering:

project = Mesos AND \
affectedVersion in (0.28, 0.28.0, 0.28.1, 0.28.2, 0.28.3) AND \
(fixVersion not in (0.28.3) OR fixVersion < 0.28.3) AND \
status = Resolved and type = Bug

This might to be like a worthwhile addition to patch release dashboards (if 
somebody with more JIRA foo could come up with an actually working query).


Cheers,

Benjamin

Re: Which service discovery mechanism could be used with mesos?

[Tomek Janiszewski]

Hi

Take a look at this SO answer http://stackoverflow.com/a/37822870/1387612

Service discovery could be Mesos agnostic by implementing
registration/quering mechanism in application. On the other hand using
discovery service that integrates with Mesos will reduce in application
code.

If you need load balancing with configurable algorithm then proxy based
solution will be good choice e.g., Traefik. DNS load balancer are hard to
configure becouse algorithm depends on client implementation (how responses
are cached and how server is chosen).

This are short answer, everything depends on use case.

Best

Tomek

pon., 7.11.2016, 11:55 użytkownik Yu Wei  napisał:

Hi Guys,


I deployed a mesos cluster with zookeeper.

Which methods could be used for service discovery and load balance?


Thanks,

Jared, (??)
Software developer
Interested in open source software, big data, Linux

Which service discovery mechanism could be used with mesos?

[Yu Wei]

Hi Guys,


I deployed a mesos cluster with zookeeper.

Which methods could be used for service discovery and load balance?


Thanks,

Jared, (??)
Software developer
Interested in open source software, big data, Linux