Re: 1.0 Release Candidate

[Vinod Kone]

This is the release dashboard:

https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328255

*NOTE: *If you have set a Fix Version of 0.29.0 on a ticket that is not a
blocker for 0.29.0/1.0 release, please unset the fix version.

On Thu, May 26, 2016 at 3:44 PM, Vinod Kone  wrote:

> Thanks for asking the questions Zameer. Wanted to give some clarification
> regarding the thought process for releasing 1.0.
>
> The reason for cutting  a 1.0, is because we want to signal that the Mesos
> project has reached a level of maturity to the wider community. Among other
> things we are confident at this point that the *foundations* we laid for
> the new APIs are mature and could be evolved in a backwards compatible way.
> We laid the foundations almost an year ago (at last MesosCon) and since
> then have been busy implementing the backend to drive the API.  Even the
> newly released design doc for the operator API is built on the same
> foundations as the scheduler/executor APIs. While we have been tweaking the
> API backend for a while now the API definitions have mostly stayed the
> same. Part of the reason it took this long is because we really wanted to
> be sure the basic building blocks were solid.
>
> MesosCon is a great opportunity for us to drum up excitement about the new
> APIs and invite them to start using/testing it. Like any other OSS project,
> as people and organizations start using the new APIs in staging and
> production, we will make stability and implementation improvements. The
> long period for the RC will also help catching issues with API foundations
> themselves. We have had a bit of chicken and egg problem having people
> consume the new APIs because most don't want to use it in production unless
> it is declared production ready and we can't call it production ready until
> someone uses them in production.
>
> Having said all that stability and production readiness is paramount for
> the project.  That is never going to change. In the case of the new APIs,
> we have developed C++ frameworks using the new APIs and having been running
> them as part of ASF CI for months now. Mesosphere, for example, also has an
> internal cluster where frameworks using these new APIs have been baking for
> a while and had done (and doing) rigorous tests (network partitions,
> scaling tests, functional tests). Community members from IBM have also been
> instrumental in testing the new APIs. We are hoping after 1.0 more people
> would be willing and excited to consume these new APIs and stress test in
> their environments.
>
> At the end of the day, while new APIs are an important part of Mesos 1.0
> it's not the only reason for cutting a 1.0 release. Mesos has a slew of
> exciting features and a thriving eco system and we would love to have more
> people excited and get a taste of it. 1.0 is just a start...
>
> Hope that helps,
>
>
> On Wed, May 25, 2016 at 4:57 PM, Zameer Manji  wrote:
>
>> I might be in the minority here, but I think cutting an RC for 1.0 right
>> now is very aggressive. Does there exist even a single framework that uses
>> the Scheduler HTTP API or the Executor HTTP API? Does anyone even use
>> these
>> APIs in production? Is there a single entity that uses the Operator API to
>> manage agents?
>>
>> I think cutting an RC right now is 100% premature until the community can
>> provide clear answers to these questions.
>>
>> I think Mesos project has been historically successful because its
>> features
>> were developed in a slow methodical manner and then battle tested by at
>> least a user before the feature was declared 'stable' and ready for use
>> for
>> everyone. I think not following those steps here for the HTTP APIs is a
>> huge error.
>>
>> On Wed, May 25, 2016 at 12:51 PM, Vinod Kone 
>> wrote:
>>
>> > Post 1.0. Jie might be able to shed more light regarding the plans for
>> > Docker Containerizer.
>> >
>> > On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder <
>> > jeffschroe...@computer.org> wrote:
>> >
>> >> Does this mean the work to deprecate the docker containerizer will be
>> >> post-1.0, or have those plans changed?
>> >>
>> >>
>> >> On Wednesday, May 25, 2016, Vinod Kone  wrote:
>> >>
>> >>> Hi folks,
>> >>>
>> >>> As discussed in the previous community sync, we plan to cut a release
>> >>> candidate for our next release (1.0) early next week.
>> >>>
>> >>> 1.0 is mainly centered around new APIs for Mesos. Please take a look
>> at
>> >>> MESOS-338  for
>> >>> blocking issues. We got some great design and testing feedback for
>> the v1
>> >>> scheduler and executor APIs. Please do the same for the in-progress v1
>> >>> operator API
>> >>> <
>> https://docs.google.com/document/d/1XfgF4jDXZDVIEWQPx6Y4glgeTTswAAxw6j8dPDAtoeI/edit?pref=2&pli=1#
>> >
>> >>> .
>> >>>
>> >>> Since this is a 1.0, we would like to do the release a little
>> >>> differently.
>> >>>
>> >>> First, the voting period for vetting the release c

Re: 1.0 Release Candidate

[Vinod Kone]

Thanks for asking the questions Zameer. Wanted to give some clarification
regarding the thought process for releasing 1.0.

The reason for cutting  a 1.0, is because we want to signal that the Mesos
project has reached a level of maturity to the wider community. Among other
things we are confident at this point that the *foundations* we laid for
the new APIs are mature and could be evolved in a backwards compatible way.
We laid the foundations almost an year ago (at last MesosCon) and since
then have been busy implementing the backend to drive the API.  Even the
newly released design doc for the operator API is built on the same
foundations as the scheduler/executor APIs. While we have been tweaking the
API backend for a while now the API definitions have mostly stayed the
same. Part of the reason it took this long is because we really wanted to
be sure the basic building blocks were solid.

MesosCon is a great opportunity for us to drum up excitement about the new
APIs and invite them to start using/testing it. Like any other OSS project,
as people and organizations start using the new APIs in staging and
production, we will make stability and implementation improvements. The
long period for the RC will also help catching issues with API foundations
themselves. We have had a bit of chicken and egg problem having people
consume the new APIs because most don't want to use it in production unless
it is declared production ready and we can't call it production ready until
someone uses them in production.

Having said all that stability and production readiness is paramount for
the project.  That is never going to change. In the case of the new APIs,
we have developed C++ frameworks using the new APIs and having been running
them as part of ASF CI for months now. Mesosphere, for example, also has an
internal cluster where frameworks using these new APIs have been baking for
a while and had done (and doing) rigorous tests (network partitions,
scaling tests, functional tests). Community members from IBM have also been
instrumental in testing the new APIs. We are hoping after 1.0 more people
would be willing and excited to consume these new APIs and stress test in
their environments.

At the end of the day, while new APIs are an important part of Mesos 1.0
it's not the only reason for cutting a 1.0 release. Mesos has a slew of
exciting features and a thriving eco system and we would love to have more
people excited and get a taste of it. 1.0 is just a start...

Hope that helps,


On Wed, May 25, 2016 at 4:57 PM, Zameer Manji  wrote:

> I might be in the minority here, but I think cutting an RC for 1.0 right
> now is very aggressive. Does there exist even a single framework that uses
> the Scheduler HTTP API or the Executor HTTP API? Does anyone even use these
> APIs in production? Is there a single entity that uses the Operator API to
> manage agents?
>
> I think cutting an RC right now is 100% premature until the community can
> provide clear answers to these questions.
>
> I think Mesos project has been historically successful because its features
> were developed in a slow methodical manner and then battle tested by at
> least a user before the feature was declared 'stable' and ready for use for
> everyone. I think not following those steps here for the HTTP APIs is a
> huge error.
>
> On Wed, May 25, 2016 at 12:51 PM, Vinod Kone  wrote:
>
> > Post 1.0. Jie might be able to shed more light regarding the plans for
> > Docker Containerizer.
> >
> > On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder <
> > jeffschroe...@computer.org> wrote:
> >
> >> Does this mean the work to deprecate the docker containerizer will be
> >> post-1.0, or have those plans changed?
> >>
> >>
> >> On Wednesday, May 25, 2016, Vinod Kone  wrote:
> >>
> >>> Hi folks,
> >>>
> >>> As discussed in the previous community sync, we plan to cut a release
> >>> candidate for our next release (1.0) early next week.
> >>>
> >>> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
> >>> MESOS-338  for
> >>> blocking issues. We got some great design and testing feedback for the
> v1
> >>> scheduler and executor APIs. Please do the same for the in-progress v1
> >>> operator API
> >>> <
> https://docs.google.com/document/d/1XfgF4jDXZDVIEWQPx6Y4glgeTTswAAxw6j8dPDAtoeI/edit?pref=2&pli=1#
> >
> >>> .
> >>>
> >>> Since this is a 1.0, we would like to do the release a little
> >>> differently.
> >>>
> >>> First, the voting period for vetting the release candidate would be a
> >>> few weeks (2-3 weeks) instead of the typical 3 days.
> >>>
> >>> Second, we are wiling to make major changes (scalability fixes, API
> >>> fixes) if there are any issues reported by the community.
> >>>
> >>> We are doing these because we really want the community to thoroughly
> >>> test the 1.0 release and give feedback.
> >>>
> >>> Thanks,
> >>>
> >>
> >>
> >> --
> >> Text by Jeff, typos by iPhone
> >>
> >
> >
>

Re: Extracting a filesystem isolation utility?

[Gilbert Song]

Hi Joshua,

Thanks for pointing this out. We understand that it would be a breaking
change in the future if Aurora release the unified containerizer support.
You want the chroot::enter call to be unified in one place instead of what
we currently doing on command executor launchtask, to avoid any other
duplicate code in executor. May I ask how urgent it is for you guys in
developing unified containerizer support? We will discuss about this issue
and create a JIRA to track it.

Thanks,
Gilbert

On Thu, May 26, 2016 at 12:38 PM, Joshua Cohen  wrote:

> Hi Mesos devs,
>
> I'm working on adding unified containerizer support to Aurora, and during
> review[1] it was pointed out that the work being done to pivot into the
> task's filesystem, mount the necessary special filesystems, etc. was a
> subset (and probably an insufficient subset at that) of what Mesos does
> when isolating a container's filesystem[2]. I wanted to propose that Mesos
> creates a utility along the lines of mesos-containerizer that makes it
> possible for an executor to share Mesos's logic without having to replicate
> it wholesale.
>
> Does this sound like something that could be done?
>
> Thanks!
>
> Joshua
>
> [1] https://reviews.apache.org/r/47853/
> [2]
>
> https://github.com/apache/mesos/blob/547f4a4d122253a42819d5746cf51593923a56bc/src/linux/fs.cpp#L599-L699
>

Extracting a filesystem isolation utility?

[Joshua Cohen]

Hi Mesos devs,

I'm working on adding unified containerizer support to Aurora, and during
review[1] it was pointed out that the work being done to pivot into the
task's filesystem, mount the necessary special filesystems, etc. was a
subset (and probably an insufficient subset at that) of what Mesos does
when isolating a container's filesystem[2]. I wanted to propose that Mesos
creates a utility along the lines of mesos-containerizer that makes it
possible for an executor to share Mesos's logic without having to replicate
it wholesale.

Does this sound like something that could be done?

Thanks!

Joshua

[1] https://reviews.apache.org/r/47853/
[2]
https://github.com/apache/mesos/blob/547f4a4d122253a42819d5746cf51593923a56bc/src/linux/fs.cpp#L599-L699

Re: Round robin DNS zookeeper record

[Zhitao Li]

Hi Joseph,

Thanks for the pointers! From the response it seems like our intended usage
should be fine, but I'll confirm separately if we decide to use that
pattern.

Thanks again.

On Wed, May 25, 2016 at 4:52 PM, Joseph Wu  wrote:

> Mesos passes the list inside between "zk://" and the first "/" directly
> into Zookeeper's C bindings.
> I'm not familiar enough with the Zookeeper API to say for certain, but it
> looks like this *does* support your round-robin scheme.
> You can double check here:
>
> https://github.com/apache/zookeeper/blob/release-3.4.8/src/c/src/zookeeper.c#L620-L650
> <
> https://github.com/apache/zookeeper/blob/release-3.4.8/src/c/src/zookeeper.c#L777
> >
>
> As for your other questions:
>
> 1) When the ZK connection is lost, Mesos will re-resolve the address as of
> MESOS-4546 (https://issues.apache.org/jira/browse/MESOS-4546).
>
> 2) Looks like ZK rotates between servers.  When one server returns an
> error, it tries the next one, in a circle.
> Increment code:
>
> https://github.com/apache/zookeeper/blob/release-3.4.8/src/c/src/zookeeper.c#L1248
> Connection code:
>
> https://github.com/apache/zookeeper/blob/release-3.4.8/src/c/src/zookeeper.c#L1578-L1580
>
> On Wed, May 25, 2016 at 3:50 PM, Zhitao Li  wrote:
>
> > Hi,
> >
> > Can someone confirm whether the zookeeper library Mesos is using well
> > supports round robin DNS?
> >
> > For example,  if I have a round robin DNS entry `zookeeper-mesos-dc`
> which
> > resolves to five A records, would the --zk flag value `
> > zk://zookeeper-mesos-dc:2181/mesos` work on master, agents and any
> > framework using libmesos driver?
> >
> > Also:
> > 1. What happens if one of the A records changes in the DNS record? Do I
> > need to restart related Mesos processes?
> > 2. What happens if one of the A records is not responsive (e.g.
> underlying
> > zookeeper server is dead)? Is the zookeeper library capable to avoid
> > the bad server?
> >
> > Some pointer for me to find out the answer individually is also greatly
> > appreciated.
> >
> > Thanks!
> >
> >
> > --
> > Cheers,
> >
> > Zhitao Li
> >
>



-- 
Cheers,

Zhitao Li

Re: CMake and CLion

[Juan Larriba]

-Hi Frank,

sorry for the delay, but my patch was submittede yestarday. Currently the
mesos agent is building using CMake either with gcc and clang. To build the
agent in Ubuntu or CentOS, you just have to create a new dir outside the
/mesos directory you cloned:

mkdir mesos_build

cd to it:
cd mesos_build

launch cmake on the mesos source dir:
cmake ../mesos

and then, make:

make

This will generate the agent, if you want to test it,

make check.

Cheers!

On 18 May 2016 at 15:06, Frank Scholten  wrote:

> Ok, thx. I pinged Alex on Twitter and I will ask him how I can help.
>
> On Wed, May 18, 2016 at 2:40 PM, Jan Schlicht  wrote:
> > Alex Clemmer is probably the right person to talk to regarding tasks for
> > improving the CMake build. Most (probably all?) devs still use
> > autoconf/automake for their every day work while MESOS-898 is still in
> > progress. That would also explain why certain things don't work yet. The
> > things that do work, though, should compile just fine. Judging from the
> > `CMakeLists.txt` that should be creating the `libmesos.so` library and
> its
> > dependencies but no agent yet.
> >
> > On Wed, May 18, 2016 at 1:21 PM, Frank Scholten 
> > wrote:
> >
> >> How can I build the agent? I can't find an add_executable definition
> >> in the CMakeLists.txt
> >>
> >> I added this to src/CMakeLists.txt
> >>
> >> {code}
> >> # Agent executable
> >> ##
> >> add_executable(${AGENT_TARGET} ${AGENT_SRC})
> >> {code}
> >>
> >> however it fails to build when I run
> >>
> >> $ make mesos-agent
> >>
> >> Also if I first run
> >>
> >> $ make mesos-0.29.0
> >>
> >> I get a lot of undefined references errors.
> >>
> >>
> >> On Wed, May 18, 2016 at 11:42 AM, haosdent  wrote:
> >> > I think you could refer to Bplotka's repo:
> >> > https://github.com/Bplotka/docker-mesos-clion
> >> >
> >> > Juan have a patch to show how build Mesos via CMake as well.
> >> > https://reviews.apache.org/r/45668/
> >> >
> >> > Noted that so far CMake only could build the Mesos Agent(Slave)
> >> component,
> >> > don't include Mesos Master.
> >> >
> >> > On Wed, May 18, 2016 at 4:58 PM, Frank Scholten <
> fr...@frankscholten.nl>
> >> > wrote:
> >> >
> >> >> Hi all,
> >> >>
> >> >> How can I help out with the CMake build of Mesos? This seems to be
> the
> >> >> epic related to it https://issues.apache.org/jira/browse/MESOS-898
> >> >>
> >> >> Are there specific issues I can look at? I run Ubuntu 16.04
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Frank
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Best Regards,
> >> > Haosdent Huang
> >>
> >
> >
> >
> > --
> > *Jan Schlicht*
> > Distributed Systems Engineer, Mesosphere
>

Re: [Design Docs] A centralized place to store all design docs

[Jay JN Guo]

hmm... that explains same creation date shared by all docs. Nice job!

However, I'm thinking to set a rule that every time a design doc being
created, it should be manually added under appropriate topic, e.g. module,
API, container, etc. If you rerun the script and generate a list of all
existing docs, we could start from that.

Or do you think it would be too much overhead to automate this via your
script?

cheers,
/J

haosdent  wrote on 05/26/2016 16:02:41:

> From: haosdent 
> To: dev 
> Date: 05/26/2016 16:05
> Subject: Re: [Design Docs] A centralized place to store all design docs
>
> Thanks @gyliu513 to pop up the link. Last time(Dec 26, 2015) I written a
> simple script to call jira api to find all links contains
"docs.google.com".
> So most design docs posted after that time point have not added to it.
>
> Refer:
> http://search-hadoop.com/m/0Vlr6NhCPaWHRX31&subj=Re+Where+s+Meses
> +design+documents
>
> >Also, flat folder structure is a bit tricky
>
> Do you have any suggestions? I could update them according to your ideas.
>
> On Thu, May 26, 2016 at 3:45 PM, Jay JN Guo 
wrote:
>
> >
> > Fantastic! Exactly what I was looking for! thx
> >
> > However I found it somewhat incomplete, for instance, Operator API
design
> > doc <
> >
> > https://docs.google.com/document/d/
> 1XfgF4jDXZDVIEWQPx6Y4glgeTTswAAxw6j8dPDAtoeI/edit#
> > > is not included.
> >
> > Also, flat folder structure is a bit tricky. Is anybody maintaining
this
> > page?
> >
> > cheers,
> > /J
> >
> > Guangya Liu  wrote on 05/26/2016 15:08:45:
> >
> > > From: Guangya Liu 
> > > To: dev 
> > > Date: 05/26/2016 15:10
> > > Subject: Re: [Design Docs] A centralized place to store all design
docs
> > >
> > > It's here
> > > https://cwiki.apache.org/confluence/display/MESOS/Design+docs
+--+Shared
> > +Links
> > >
> > > On Thu, May 26, 2016 at 2:16 PM, Jay JN Guo 
> > wrote:
> > >
> > > >
> > > > Hi folk,
> > > >
> > > > Do we have a place (e.g. google driver directory) to aggregate all
> > design
> > > > docs? I think it makes life easier for people to navigate and dig
up
> > > > history.
> > > >
> > > > cheers,
> > > > /J
> > > >
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang

Re: [Design Docs] A centralized place to store all design docs

[haosdent]

Certainly I would do that. The script just find out all google docs links.
Actually we still find their titles from docs and add to wiki one by one
because our design docs may have different formats.

On Thu, May 26, 2016 at 5:14 PM, Abhishek Dasgupta <
a10gu...@linux.vnet.ibm.com> wrote:

> Hi haosdent,
>
> Could we run that script again to sync up to the newest versions of doc?
>
>
> On বৃহস্পতিবার 26 মে 2016 01:32 অপরাহ্ণ, haosdent wrote:
>
>> Thanks @gyliu513 to pop up the link. Last time(Dec 26, 2015) I written a
>> simple script to call jira api to find all links contains "
>> docs.google.com".
>> So most design docs posted after that time point have not added to it.
>>
>> Refer:
>>
>> http://search-hadoop.com/m/0Vlr6NhCPaWHRX31&subj=Re+Where+s+Meses+design+documents
>>
>> Also, flat folder structure is a bit tricky
>>>
>> Do you have any suggestions? I could update them according to your ideas.
>>
>> On Thu, May 26, 2016 at 3:45 PM, Jay JN Guo 
>> wrote:
>>
>> Fantastic! Exactly what I was looking for! thx
>>>
>>> However I found it somewhat incomplete, for instance, Operator API design
>>> doc <
>>>
>>>
>>> https://docs.google.com/document/d/1XfgF4jDXZDVIEWQPx6Y4glgeTTswAAxw6j8dPDAtoeI/edit#
>>>
 is not included.

>>> Also, flat folder structure is a bit tricky. Is anybody maintaining this
>>> page?
>>>
>>> cheers,
>>> /J
>>>
>>> Guangya Liu  wrote on 05/26/2016 15:08:45:
>>>
>>> From: Guangya Liu 
 To: dev 
 Date: 05/26/2016 15:10
 Subject: Re: [Design Docs] A centralized place to store all design docs

 It's here
 https://cwiki.apache.org/confluence/display/MESOS/Design+docs+--+Shared

>>> +Links
>>>
 On Thu, May 26, 2016 at 2:16 PM, Jay JN Guo 

>>> wrote:
>>>
 Hi folk,
>
> Do we have a place (e.g. google driver directory) to aggregate all
>
 design
>>>
 docs? I think it makes life easier for people to navigate and dig up
> history.
>
> cheers,
> /J
>
>
>>
>>
>


-- 
Best Regards,
Haosdent Huang

Re: [Design Docs] A centralized place to store all design docs

[Abhishek Dasgupta]

Hi haosdent,

Could we run that script again to sync up to the newest versions of doc?

On বৃহস্পতিবার 26 মে 2016 01:32 অপরাহ্ণ, haosdent wrote:

Thanks @gyliu513 to pop up the link. Last time(Dec 26, 2015) I written a
simple script to call jira api to find all links contains "docs.google.com".
So most design docs posted after that time point have not added to it.

Refer:
http://search-hadoop.com/m/0Vlr6NhCPaWHRX31&subj=Re+Where+s+Meses+design+documents


Also, flat folder structure is a bit tricky

Do you have any suggestions? I could update them according to your ideas.

On Thu, May 26, 2016 at 3:45 PM, Jay JN Guo  wrote:


Fantastic! Exactly what I was looking for! thx

However I found it somewhat incomplete, for instance, Operator API design
doc <

https://docs.google.com/document/d/1XfgF4jDXZDVIEWQPx6Y4glgeTTswAAxw6j8dPDAtoeI/edit#

is not included.

Also, flat folder structure is a bit tricky. Is anybody maintaining this
page?

cheers,
/J

Guangya Liu  wrote on 05/26/2016 15:08:45:


From: Guangya Liu 
To: dev 
Date: 05/26/2016 15:10
Subject: Re: [Design Docs] A centralized place to store all design docs

It's here
https://cwiki.apache.org/confluence/display/MESOS/Design+docs+--+Shared

+Links

On Thu, May 26, 2016 at 2:16 PM, Jay JN Guo 

wrote:

Hi folk,

Do we have a place (e.g. google driver directory) to aggregate all

design

docs? I think it makes life easier for people to navigate and dig up
history.

cheers,
/J

Re: [Design Docs] A centralized place to store all design docs

[Zhou Z Xing]

wonder if community has a process to share and control the design docs. So
any new design doc shall be published and shared in there?

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




From:   Jay JN Guo/China/IBM@IBMCN
To: dev@mesos.apache.org
Date:   2016-05-26 下午 04:01
Subject:Re: [Design Docs] A centralized place to store all design docs




Fantastic! Exactly what I was looking for! thx

However I found it somewhat incomplete, for instance, Operator API design
doc <
https://docs.google.com/document/d/1XfgF4jDXZDVIEWQPx6Y4glgeTTswAAxw6j8dPDAtoeI/edit#

> is not included.

Also, flat folder structure is a bit tricky. Is anybody maintaining this
page?

cheers,
/J

Guangya Liu  wrote on 05/26/2016 15:08:45:

> From: Guangya Liu 
> To: dev 
> Date: 05/26/2016 15:10
> Subject: Re: [Design Docs] A centralized place to store all design docs
>
> It's here
> https://cwiki.apache.org/confluence/display/MESOS/Design+docs+--+Shared
+Links
>
> On Thu, May 26, 2016 at 2:16 PM, Jay JN Guo 
wrote:
>
> >
> > Hi folk,
> >
> > Do we have a place (e.g. google driver directory) to aggregate all
design
> > docs? I think it makes life easier for people to navigate and dig up
> > history.
> >
> > cheers,
> > /J
> >

Re: [Design Docs] A centralized place to store all design docs

[haosdent]

Thanks @gyliu513 to pop up the link. Last time(Dec 26, 2015) I written a
simple script to call jira api to find all links contains "docs.google.com".
So most design docs posted after that time point have not added to it.

Refer:
http://search-hadoop.com/m/0Vlr6NhCPaWHRX31&subj=Re+Where+s+Meses+design+documents

>Also, flat folder structure is a bit tricky

Do you have any suggestions? I could update them according to your ideas.

On Thu, May 26, 2016 at 3:45 PM, Jay JN Guo  wrote:

>
> Fantastic! Exactly what I was looking for! thx
>
> However I found it somewhat incomplete, for instance, Operator API design
> doc <
>
> https://docs.google.com/document/d/1XfgF4jDXZDVIEWQPx6Y4glgeTTswAAxw6j8dPDAtoeI/edit#
> > is not included.
>
> Also, flat folder structure is a bit tricky. Is anybody maintaining this
> page?
>
> cheers,
> /J
>
> Guangya Liu  wrote on 05/26/2016 15:08:45:
>
> > From: Guangya Liu 
> > To: dev 
> > Date: 05/26/2016 15:10
> > Subject: Re: [Design Docs] A centralized place to store all design docs
> >
> > It's here
> > https://cwiki.apache.org/confluence/display/MESOS/Design+docs+--+Shared
> +Links
> >
> > On Thu, May 26, 2016 at 2:16 PM, Jay JN Guo 
> wrote:
> >
> > >
> > > Hi folk,
> > >
> > > Do we have a place (e.g. google driver directory) to aggregate all
> design
> > > docs? I think it makes life easier for people to navigate and dig up
> > > history.
> > >
> > > cheers,
> > > /J
> > >
>



-- 
Best Regards,
Haosdent Huang

Re: [Design Docs] A centralized place to store all design docs

[Jay JN Guo]

Fantastic! Exactly what I was looking for! thx

However I found it somewhat incomplete, for instance, Operator API design
doc <
https://docs.google.com/document/d/1XfgF4jDXZDVIEWQPx6Y4glgeTTswAAxw6j8dPDAtoeI/edit#
> is not included.

Also, flat folder structure is a bit tricky. Is anybody maintaining this
page?

cheers,
/J

Guangya Liu  wrote on 05/26/2016 15:08:45:

> From: Guangya Liu 
> To: dev 
> Date: 05/26/2016 15:10
> Subject: Re: [Design Docs] A centralized place to store all design docs
>
> It's here
> https://cwiki.apache.org/confluence/display/MESOS/Design+docs+--+Shared
+Links
>
> On Thu, May 26, 2016 at 2:16 PM, Jay JN Guo 
wrote:
>
> >
> > Hi folk,
> >
> > Do we have a place (e.g. google driver directory) to aggregate all
design
> > docs? I think it makes life easier for people to navigate and dig up
> > history.
> >
> > cheers,
> > /J
> >

Re: [Design Docs] A centralized place to store all design docs

[Abhishek Dasgupta]

+100 for this great idea.

On বৃহস্পতিবার 26 মে 2016 11:46 পূর্বাহ্ণ, Jay JN Guo wrote:

Hi folk,

Do we have a place (e.g. google driver directory) to aggregate all design
docs? I think it makes life easier for people to navigate and dig up
history.

cheers,
/J

Re: [Design Docs] A centralized place to store all design docs

[Guangya Liu]

It's here
https://cwiki.apache.org/confluence/display/MESOS/Design+docs+--+Shared+Links

On Thu, May 26, 2016 at 2:16 PM, Jay JN Guo  wrote:

>
> Hi folk,
>
> Do we have a place (e.g. google driver directory) to aggregate all design
> docs? I think it makes life easier for people to navigate and dig up
> history.
>
> cheers,
> /J
>