回复：欢迎mesos牛人来滴滴贡献力量

[黑洞]

不错，多多交流


--






















https://github.com/heidsoft

Research: Cloud computing (cloud security), Big Data (data analysis)
Key-Learning: Linux / C / C + + / JAVA / Python/ R
Email: heids...@qq.com



 




-- 原始邮件 --
发件人: "许令波(基础平台部)";;
发送时间: 2017年2月8日(星期三) 下午2:23
收件人: "dev@mesos.apache.org"; 
抄送: "许令波(基础平台部)"; 
主题: 欢迎mesos牛人来滴滴贡献力量



目前滴滴想构建基于mesos的统一资源的调度平台，这个调度平台会支持前台web 
app应用、中间件系统、在线和离线大数据系统以及机器学习平台的机器,目标是管理全公司所有的机器资源，最终实现机器资源的在离线混部和峰谷调度从而提升机器的利用效率。

预计初步规模会达到10w台以上，随著滴滴机器的不断增加，建成后估计会成为国内最大规模的mesos集群,目前滴滴已经是中国仅次于淘宝的第二大在线交易平台，应用场景和技术挑战可想而知！

另外滴滴也会积极拥抱开源力量，做出的产品也会积极回报给社区，我们的大boss章文嵩博士是lvs创始人也是中国开源社区的积极推动者，所以欢迎做mesos相关的同学愿意来滴滴，帮助建设我们的平台

如果有兴趣可以联系我，微信：xulingbo0201,邮件：xulin...@didichuxing.com

多谢！

Re: 欢迎mesos牛人来滴滴贡献力量

[haosdent]

Simple translation:

DIDI(http://www.xiaojukeji.com/index/index) are going to build the unified
platform based on Mesos. The initial design capacity is 100, 000 servers.
Now DIDI is the second largest online trading platform in China only to
Alibaba. Welcome to contact lingbo (xulin...@didichuxing.com) if you
interested.

2017-02-08 14:23 GMT+08:00 许令波(基础平台部) :

> 目前滴滴想构建基于mesos的统一资源的调度平台，这个调度平台会支持前台web app应用、中间件系统、在线和离线大数据系统以及机器学习平台的机器,
> 目标是管理全公司所有的机器资源，最终实现机器资源的在离线混部和峰谷调度从而提升机器的利用效率。
>
> 预计初步规模会达到10w台以上，随著滴滴机器的不断增加，建成后估计会成为国内最大规模的mesos集群,
> 目前滴滴已经是中国仅次于淘宝的第二大在线交易平台，应用场景和技术挑战可想而知！
>
> 另外滴滴也会积极拥抱开源力量，做出的产品也会积极回报给社区，我们的大boss章文嵩博士是lvs创始人也是中国开源社区的积
> 极推动者，所以欢迎做mesos相关的同学愿意来滴滴，帮助建设我们的平台
>
> 如果有兴趣可以联系我，微信：xulingbo0201,邮件：xulin...@didichuxing.com
>
> 多谢！
>



-- 
Best Regards,
Haosdent Huang

欢迎mesos牛人来滴滴贡献力量

[基础平台部]

目前滴滴想构建基于mesos的统一资源的调度平台，这个调度平台会支持前台web 
app应用、中间件系统、在线和离线大数据系统以及机器学习平台的机器,目标是管理全公司所有的机器资源，最终实现机器资源的在离线混部和峰谷调度从而提升机器的利用效率。

预计初步规模会达到10w台以上，随著滴滴机器的不断增加，建成后估计会成为国内最大规模的mesos集群,目前滴滴已经是中国仅次于淘宝的第二大在线交易平台，应用场景和技术挑战可想而知！

另外滴滴也会积极拥抱开源力量，做出的产品也会积极回报给社区，我们的大boss章文嵩博士是lvs创始人也是中国开源社区的积极推动者，所以欢迎做mesos相关的同学愿意来滴滴，帮助建设我们的平台

如果有兴趣可以联系我，微信：xulingbo0201,邮件：xulin...@didichuxing.com

多谢！

[VOTE] Release Apache Mesos 1.1.1 (rc1)

[Alex R]

Hi all,

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

1.1.1 includes the following:

** Bug
  * [MESOS-6002] - The whiteout file cannot be removed correctly using aufs
backend.
  * [MESOS-6010] - Docker registry puller shows decode error "No response
decoded".
  * [MESOS-6142] - Frameworks may RESERVE for an arbitrary role.
  * [MESOS-6360] - The handling of whiteout files in provisioner is not
correct.
  * [MESOS-6411] - Add documentation for CNI port-mapper plugin.
  * [MESOS-6526] - `mesos-containerizer launch --environment` exposes
executor env vars in `ps`.
  * [MESOS-6571] - Add "--task" flag to mesos-execute.
  * [MESOS-6597] - Include v1 Operator API protos in generated JAR and
python packages.
  * [MESOS-6621] - SSL downgrade path will CHECK-fail when using both
temporary and persistent sockets.
  * [MESOS-6624] - Master WebUI does not work on Firefox 45.
  * [MESOS-6676] - Always re-link with scheduler during re-registration.
  * [MESOS-6848] - The default executor does not exit if a single task pod
fails.
  * [MESOS-6852] - Nested container's launch command is not set correctly
in docker/runtime isolator.
  * [MESOS-6917] - Segfault when the executor sets an invalid UUID when
sending a status update.
  * [MESOS-7008] - Quota not recovered from registry in empty cluster.

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.1-rc1


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

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

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

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

Please vote on releasing this package as Apache Mesos 1.1.1!

The vote is open until Fri Feb 10 23:59:59 CET 2017 and passes if a
majority of at least 3 +1 PMC votes are cast.

[ ] +1 Release this package as Apache Mesos 1.1.1
[ ] -1 Do not release this package because ...

Thanks,
Till & Alex

Re: How to consistent handle default values for message types

[Yan Xu]

> On Feb 7, 2017, at 11:13 AM, Joris Van Remoortere  wrote:
> 
>> 
>> we should be able to not require them to be set and assume the defaults?
> 
> 
> What happens when we add a field without a default value to the message?
> If users can assume they don't need to set the message this may cause
> backwards compatibility issues in the future.

We can't. So this is why I said such message should semantically sound like a 
config object with defaults. (I think the backoff example I gave fits this 
criterion).
If we really need to add such a field, we would have to use a different message.

> 
> Maybe I am not understanding whether you mean leaving the message unset, or
> the field?

I meant leaving the message unset.

> 
> —
> *Joris Van Remoortere*
> Mesosphere
> 
> On Thu, Feb 2, 2017 at 3:06 PM, Yan Xu  wrote:
> 
>> With protobuf you can specify custom default values for scalar types
>> (proto2 at least) but not message types, e.g.,
>> 
>> ```
>> message Filters {
>> // Time to consider unused resources refused. Note that all unused
>> // resources will be considered refused and use the default value
>> // (below) regardless of whether Filters was passed to
>> // SchedulerDriver::launchTasks. You MUST pass Filters with this
>> // field set to change this behavior (i.e., get another offer which
>> // includes unused resources sooner or later than the default).
>> optional double refuse_seconds = 1 [default = 5.0];
>> }
>> ```
>> 
>> However, the message `Filters` essential has a default value because *all*
>> its
>> fields have default values. It all depends on whether the receiver chooses
>> to check it is not set or directly accesses it and gets the default values.
>> 
>> When we reference the type in other messages, e.g.,
>> 
>> ```
>> message Accept {
>>   repeated OfferID offer_ids = 1;
>>   repeated Offer.Operation operations = 2;
>>   optional Filters filters = 3;
>> }
>> ```
>> 
>> We are not explicitly telling users what's going to happen when `filters`
>> is not set. The master just directly uses it without checking.
>> 
>> It does feel intuitive to me that "*if all the fields in a message have
>> default values, and it semantically feels like a config, then we can just
>> interpret them when unset as indication to use defaults*".
>> 
>> However we probably should document it better.
>> 
>> To generalize it further, for something like this with multiple fields
>> 
>> ```
>> message ExponentialBackoff {
>> optional double initial_interval_seconds = 1 [default = 0.5];
>> optional double max_interval_seconds = 2 [default = 300.0];
>> optional double randomization_factor = 3 [default = 0.5];
>> optional double max_elapsed_seconds = 4 [default = 2592000.0];
>> }
>> ```
>> 
>> we should be able to not require them to be set and assume the defaults?
>> 
>> One step further, if the message has recursively nested messages with
>> default values, we can treat the parent message as having a default value
>> too?
>> 
>> Thoughts?
>> 
>> Yan
>> 

Re: Tracking deprecated features

[Ilya Pronin]

I agree with Neil that deprecation/experimental status should be
duplicated on the website/docs. Users shouldn't have to scan JIRA in
search for documentation.

On Tue, Feb 7, 2017 at 4:33 PM, Neil Conway  wrote:
> Strongly agree that this can and should be improved! Two 
> questions/suggestions:
>
> (1) Should we use JIRA, the website/docs, or both? If we only use
> JIRA, it might not be obvious to users that, e.g., the "--roles"
> master flag is deprecated. An alternative would be a table in the
> docs, listing (a) when a feature was deprecated, (b) when a feature
> will be removed, (c) links to JIRAs.
>
> (2) In some ways, experimental features are the inverse of deprecated
> features (e.g., typical evolution might be experimental -> stable ->
> deprecated -> removed). We should make it more clear to users (a)
> which features are currently experimental, and (b) when those
> experimental features graduate to being "stable". I wonder if we could
> use a similar system to what you propose for making this information
> more clear to users.
>
> Neil
>
> One thing I wonder about is whether we should use the website/docs,
> JIRA, or both
> On Tue, Feb 7, 2017 at 2:56 AM, Benjamin Bannier
>  wrote:
>> Hi,
>>
>> we currently track deprecation of features largely through TODOs in the 
>> source code. Here we typically write down a release at which a deprecated 
>> feature should be removed.
>>
>> I believe this is less than optimal since
>>
>> * it is hard for users of our APIs to track when a deprecated feature is 
>> actually removed,
>> * it seems to encourage versioning-related discussions to happen in 
>> potentially low-visibility review requests instead of JIRA tickets,
>> * this approach can lead to wrong or misleading information in the code as 
>> our versioning policies evolve and mature, and
>> * poor trackability of outstanding deprecations leads to lots of missed 
>> opportunities to remove features already out of their deprecation cycle as 
>> we prepare releases.
>>
>> I would like to propose to use JIRA for tracking deprecations instead.
>>
>> A possible approach would be:
>>
>> 1) When a feature becomes deprecated, a JIRA ticket is created for its 
>> removal. The ticket can be referenced in the source code.
>> 2) The ticket should be tagged with e.g. `deprecation`, and optimally link 
>> back to the ticket triggering the deprecation.
>> 3) A target version is set in collaboration with maintainers of the 
>> versioning policy.
>> 4) The release process is updated to involve bumping target versions of 
>> unfixed deprecation tickets to the following version.
>>
>> I believe with this we would be able to better keep track and ultimately fix 
>> tech debt, as well as better improve communicating breaking to users.
>>
>> Any thoughts?
>>
>>
>> Cheers,
>>
>> Benjamin

Re: Tracking deprecated features

[Neil Conway]

Strongly agree that this can and should be improved! Two questions/suggestions:

(1) Should we use JIRA, the website/docs, or both? If we only use
JIRA, it might not be obvious to users that, e.g., the "--roles"
master flag is deprecated. An alternative would be a table in the
docs, listing (a) when a feature was deprecated, (b) when a feature
will be removed, (c) links to JIRAs.

(2) In some ways, experimental features are the inverse of deprecated
features (e.g., typical evolution might be experimental -> stable ->
deprecated -> removed). We should make it more clear to users (a)
which features are currently experimental, and (b) when those
experimental features graduate to being "stable". I wonder if we could
use a similar system to what you propose for making this information
more clear to users.

Neil

One thing I wonder about is whether we should use the website/docs,
JIRA, or both
On Tue, Feb 7, 2017 at 2:56 AM, Benjamin Bannier
 wrote:
> Hi,
>
> we currently track deprecation of features largely through TODOs in the 
> source code. Here we typically write down a release at which a deprecated 
> feature should be removed.
>
> I believe this is less than optimal since
>
> * it is hard for users of our APIs to track when a deprecated feature is 
> actually removed,
> * it seems to encourage versioning-related discussions to happen in 
> potentially low-visibility review requests instead of JIRA tickets,
> * this approach can lead to wrong or misleading information in the code as 
> our versioning policies evolve and mature, and
> * poor trackability of outstanding deprecations leads to lots of missed 
> opportunities to remove features already out of their deprecation cycle as we 
> prepare releases.
>
> I would like to propose to use JIRA for tracking deprecations instead.
>
> A possible approach would be:
>
> 1) When a feature becomes deprecated, a JIRA ticket is created for its 
> removal. The ticket can be referenced in the source code.
> 2) The ticket should be tagged with e.g. `deprecation`, and optimally link 
> back to the ticket triggering the deprecation.
> 3) A target version is set in collaboration with maintainers of the 
> versioning policy.
> 4) The release process is updated to involve bumping target versions of 
> unfixed deprecation tickets to the following version.
>
> I believe with this we would be able to better keep track and ultimately fix 
> tech debt, as well as better improve communicating breaking to users.
>
> Any thoughts?
>
>
> Cheers,
>
> Benjamin

Re: Tracking deprecated features

[Vinod Kone]

Sgtm 

@vinodkone

> On Feb 7, 2017, at 2:56 AM, Benjamin Bannier  
> wrote:
> 
> Hi,
> 
> we currently track deprecation of features largely through TODOs in the 
> source code. Here we typically write down a release at which a deprecated 
> feature should be removed.
> 
> I believe this is less than optimal since
> 
> * it is hard for users of our APIs to track when a deprecated feature is 
> actually removed,
> * it seems to encourage versioning-related discussions to happen in 
> potentially low-visibility review requests instead of JIRA tickets,
> * this approach can lead to wrong or misleading information in the code as 
> our versioning policies evolve and mature, and
> * poor trackability of outstanding deprecations leads to lots of missed 
> opportunities to remove features already out of their deprecation cycle as we 
> prepare releases.
> 
> I would like to propose to use JIRA for tracking deprecations instead.
> 
> A possible approach would be:
> 
> 1) When a feature becomes deprecated, a JIRA ticket is created for its 
> removal. The ticket can be referenced in the source code.
> 2) The ticket should be tagged with e.g. `deprecation`, and optimally link 
> back to the ticket triggering the deprecation.
> 3) A target version is set in collaboration with maintainers of the 
> versioning policy.
> 4) The release process is updated to involve bumping target versions of 
> unfixed deprecation tickets to the following version.
> 
> I believe with this we would be able to better keep track and ultimately fix 
> tech debt, as well as better improve communicating breaking to users.
> 
> Any thoughts?
> 
> 
> Cheers,
> 
> Benjamin

Tracking deprecated features

[Benjamin Bannier]

Hi,

we currently track deprecation of features largely through TODOs in the source 
code. Here we typically write down a release at which a deprecated feature 
should be removed.

I believe this is less than optimal since

* it is hard for users of our APIs to track when a deprecated feature is 
actually removed,
* it seems to encourage versioning-related discussions to happen in potentially 
low-visibility review requests instead of JIRA tickets,
* this approach can lead to wrong or misleading information in the code as our 
versioning policies evolve and mature, and
* poor trackability of outstanding deprecations leads to lots of missed 
opportunities to remove features already out of their deprecation cycle as we 
prepare releases.

I would like to propose to use JIRA for tracking deprecations instead.

A possible approach would be:

1) When a feature becomes deprecated, a JIRA ticket is created for its removal. 
The ticket can be referenced in the source code.
2) The ticket should be tagged with e.g. `deprecation`, and optimally link back 
to the ticket triggering the deprecation.
3) A target version is set in collaboration with maintainers of the versioning 
policy.
4) The release process is updated to involve bumping target versions of unfixed 
deprecation tickets to the following version.

I believe with this we would be able to better keep track and ultimately fix 
tech debt, as well as better improve communicating breaking to users.

Any thoughts?


Cheers,

Benjamin