Re: Accessibility For Mesos Web-GUI

[haosdent]

Hi, @Andrew. Thank you very much for providing details. I try VoiceOver on
webui and it isn't friendly. As @Adam said, I create a ticket on
https://issues.apache.org/jira/browse/MESOS-5185 by copying your proposal
as description. Feel free to update it or add more comments.

On Tue, Apr 12, 2016 at 11:07 AM, Andrew Li  wrote:

> Hi haosdent:
> I mean Mesos web GUI do not *fully* support Accessibility features.
> For contents
> in Mesos webui, screen reader can recognize
> partially, but not all of them.
>
> For details, you can refer to
> https://msdn.microsoft.com/en-us/library/aa291312(v=vs.71).aspx
>
> and https://www.w3.org/standards/webdesign/accessibility
>
> 2016-04-11 22:43 GMT+08:00 haosdent :
>
> > Hi, about "Mesos GUI do not have fully support Accessibility features",
> may
> > you provide more details? Does screen reader could not recognize the
> > contents in Mesos webui?
> >
> > On Mon, Apr 11, 2016 at 10:10 PM, Andrew Li 
> wrote:
> >
> > > Hello everyone:
> > >
> > > I find that Mesos GUI do not have fully support Accessibility features
> > for
> > > disabled people to use the web GUI.
> > >
> > > For example:
> > >
> > > Web GUI can support screen reader to read page content for blind
> person.
> > > so we can fix some issues such as making Mesos Web GUI pages to support
> > > WAI-ARIA standard
> > > (https://www.w3.org/WAI/intro/aria)
> > >
> > > so How about my proposal?  need your comments.
> > >
> > > Thanks for all your help.
> > >
> >
> >
> >
> > --
> > Best Regards,
> > Haosdent Huang
> >
>



-- 
Best Regards,
Haosdent Huang

Re: Accessibility For Mesos Web-GUI

[Andrew Li]

Hi haosdent:
I mean Mesos web GUI do not *fully* support Accessibility features.
For contents
in Mesos webui, screen reader can recognize
partially, but not all of them.

For details, you can refer to
https://msdn.microsoft.com/en-us/library/aa291312(v=vs.71).aspx

and https://www.w3.org/standards/webdesign/accessibility

2016-04-11 22:43 GMT+08:00 haosdent :

> Hi, about "Mesos GUI do not have fully support Accessibility features", may
> you provide more details? Does screen reader could not recognize the
> contents in Mesos webui?
>
> On Mon, Apr 11, 2016 at 10:10 PM, Andrew Li  wrote:
>
> > Hello everyone:
> >
> > I find that Mesos GUI do not have fully support Accessibility features
> for
> > disabled people to use the web GUI.
> >
> > For example:
> >
> > Web GUI can support screen reader to read page content for blind person.
> > so we can fix some issues such as making Mesos Web GUI pages to support
> > WAI-ARIA standard
> > (https://www.w3.org/WAI/intro/aria)
> >
> > so How about my proposal?  need your comments.
> >
> > Thanks for all your help.
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Questions about Docker related tests in Mesos

[zhiwei]

Hi Gilbert, do you have any updates on about this issue?

When will you use the local build Docker image for Docker related testing?

On Mon, Mar 14, 2016 at 9:44 PM, zhiwei  wrote:

> Hi Gibert,
>
> I tested your patch, it works on ppc64le, but there is an issue that the
> architecture in manifest file is hardcode to amd64[1].
>
> This field is currently not used by Docker engine, but I think you can
> enhance it to use `os.uname().machine` [2]. Or I can submit a patch for
> this.
>
> And could you make it create and load the image before running Docker
> related tests?
>
> [1]:
> https://github.com/apache/mesos/blob/69b2ad528dd79979a8ee113a8edbbab2669e32e6/src/tests/containerizer/docker_archive.hpp#L150
> [2]:
> https://github.com/docker/distribution/blob/master/docs/spec/manifest-v2-2.md#manifest-list-field-descriptions
>
>
> On Sat, Mar 12, 2016 at 8:45 PM, zhiwei  wrote:
>
>> this because the architecture, alpine is x86_64, the power is ppc64le.
>>
>> this may help in IBM Power.
>> On Mar 12, 2016 01:10, "Gilbert Song"  wrote:
>>
>>> Hi Zhiwei,
>>>
>>> I am trying to understand why 'alpine' is not compatible with IBM Power
>>> platform. Is it because of the image's rootfs?
>>>
>>> We currently have a JIRA(
>>> https://issues.apache.org/jira/browse/MESOS-4684)
>>> in progress to create a local docker image, which is used for docker
>>> runtime isolator local tests. This test image cp the host's linux rootfs.
>>> Does it possibly help in your case?
>>>
>>> Cheers,
>>> Gilbert
>>>
>>> On Fri, Mar 11, 2016 at 2:30 AM, zhiwei  wrote:
>>>
>>> > Yes, I prefer to create specific mesos test images and make them
>>> > configurable in configuration file.
>>> >
>>> > On Fri, Mar 11, 2016 at 6:20 PM, Alex Rukletsov 
>>> > wrote:
>>> >
>>> > > It also looks strange to me that we use "random" containers in Mesos
>>> > tests.
>>> > > The proper way would be to have "mesos" or "apache" account on
>>> docker hub
>>> > > managed by PMC. Do you think it's worth to set up one or it's too
>>> much
>>> > time
>>> > > investment?
>>> > >
>>> > > On Thu, Mar 10, 2016 at 12:19 PM, Jan Schlicht 
>>> > wrote:
>>> > >
>>> > > > Hi Zhiwei,
>>> > > >
>>> > > > I was thinking about this as well, but for different reasons:
>>> Pulling
>>> > in
>>> > > > Docker images for tests is not the ideal solution. Sure, testing a
>>> > `sleep
>>> > > > 1000` should work, but testing an executor leaves some questions
>>> on how
>>> > > to
>>> > > > handle changes/deprecation of the interfaces. It's not a pressing
>>> issue
>>> > > > right now, but might become one in the future.
>>> > > >
>>> > > > I think this is also what Timothy had in mind with his comment
>>> > (Timothy,
>>> > > > please correct me if I'm wrong): These problems can be resolved by
>>> > using
>>> > > > local Docker images, ideally ones that are created during `make
>>> check`.
>>> > > But
>>> > > > this would create new problems. Either we would have to build
>>> libmesos
>>> > > > inside our local container -- to be able to build test executors --
>>> > which
>>> > > > would take a long time, or we'd have to make sure that the
>>> container
>>> > > > environment is the same as the dev environment, to be able to copy
>>> test
>>> > > > executors into it, which isn't easy unless we'd restrict ourselves
>>> to
>>> > > only
>>> > > > a couple of environments.
>>> > > >
>>> > > > Cheers,
>>> > > > Jan
>>> > > >
>>> > > > On Thu, Mar 10, 2016 at 11:25 AM, zhiwei 
>>> wrote:
>>> > > >
>>> > > > > Hi all,
>>> > > > >
>>> > > > > The Docker related test cases that hardcoded "alpine" as the
>>> Docker
>>> > > image
>>> > > > > which caused test cases failed on IBM Power platform, since the
>>> > Docker
>>> > > > > image "alpine" is not compatible with IBM Power platform.
>>> > > > >
>>> > > > > And I saw an inline comment by Timothy: "// TODO(tnachen): Use
>>> local
>>> > > > image
>>> > > > > to test if possible."
>>> > > > >
>>> > > > > So just wonder if someone has plan to implement this, or could
>>> you
>>> > give
>>> > > > me
>>> > > > > some tips? I can implement this.
>>> > > > >
>>> > > > > Following are the images that used in Mesos test cases:
>>> > > > >
>>> > > > > 1. alpine
>>> > > > > 2. mesosphere/alpine-expect
>>> > > > > 3. mesosphere/inky
>>> > > > > 4. mesosphere/test-executor
>>> > > > > 5. tnachen/test-executor
>>> > > > >
>>> > > > >
>>> > > > > Thanks,
>>> > > > > Zhiwei
>>> > > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > --
>>> > > > *Jan Schlicht*
>>> > > > Distributed Systems Engineer, Mesosphere
>>> > > >
>>> > >
>>> >
>>>
>>
>

Re: Accessibility For Mesos Web-GUI

[Adam Bordelon]

Sounds great! (although we're short on WebUI maintainers)
Could you file a JIRA at https://issues.apache.org/jira/browse/MESOS
See http://mesos.apache.org/documentation/latest/reporting-a-bug/

On Mon, Apr 11, 2016 at 7:43 AM, haosdent  wrote:
> Hi, about "Mesos GUI do not have fully support Accessibility features", may
> you provide more details? Does screen reader could not recognize the
> contents in Mesos webui?
>
> On Mon, Apr 11, 2016 at 10:10 PM, Andrew Li  wrote:
>
>> Hello everyone:
>>
>> I find that Mesos GUI do not have fully support Accessibility features for
>> disabled people to use the web GUI.
>>
>> For example:
>>
>> Web GUI can support screen reader to read page content for blind person.
>> so we can fix some issues such as making Mesos Web GUI pages to support
>> WAI-ARIA standard
>> (https://www.w3.org/WAI/intro/aria)
>>
>> so How about my proposal?  need your comments.
>>
>> Thanks for all your help.
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang

Re: [VOTE] Release Apache Mesos 0.28.1 (rc2)

[Kapil Arya]

+1 (binding)

CI runs with: amd64/centos/6 amd64/centos/7 amd64/debian/jessie
amd64/ubuntu/precise amd64/ubuntu/trusty amd64/ubuntu/vivid
amd64/ubuntu/wily

On Wed, Apr 6, 2016 at 11:51 PM, Vinod Kone  wrote:

> +1 (binding)
>
> Tested on ASF CI. There was one flaky test that's new:
> https://issues.apache.org/jira/browse/MESOS-5139
>
> Configuration Matrix gcc clang
> centos:7 --verbose --enable-libevent --enable-ssl [image: Success]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/13/COMPILER=gcc,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
> [image:
> Not run]
> --verbose [image: Success]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/13/COMPILER=gcc,CONFIGURATION=--verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
> [image:
> Not run]
> ubuntu:14.04 --verbose --enable-libevent --enable-ssl [image: Success]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/13/COMPILER=gcc,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
> [image:
> Failed]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/13/COMPILER=clang,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
> --verbose [image: Success]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/13/COMPILER=gcc,CONFIGURATION=--verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
> [image:
> Success]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/13/COMPILER=clang,CONFIGURATION=--verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
>
> On Wed, Apr 6, 2016 at 7:34 PM, Michael Park  wrote:
>
> > +1 (binding)
> >
> > Internal CI results with the corresponding JIRA tickets for the failed
> > tests:
> >
> > CentOS 6 (non-SSL):
> > CentOS 6 (SSL):
> >   - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
> > (MESOS-4047 ,
> > MESOS-4053 )
> >
> > CentOS 7 (non-SSL):
> >   - HealthCheckTest.ROOT_DOCKER_DockerHealthyTask
> > (MESOS-4604 )
> >
> > CentOS 7 (SSL):
> >   -
> >
> >
> LinuxFilesystemIsolatorTest.ROOT_ChangeRootFilesystemCommandExecutorWithVolumes
> > (Segfault during test teardown, likely addressed in 0.29.0 by
> > MESOS-4633
> >  and MESOS-4634
> > )
> >
> > Debian 8 (non-SSL):
> > Debian 8 (SSL):
> >   - HealthCheckTest.ROOT_DOCKER_DockerHealthyTask
> > (MESOS-4604 )
> >
> > Ubuntu 12 (non-SSL): Success!
> > Ubuntu 12 (SSL):Success!
> > Ubuntu 14 (non-SSL): Success!
> > Ubuntu 14 (SSL):Success!
> > Ubuntu 15 (non-SSL): Success!
> > Ubuntu 15 (SSL):Success!
> >
> > On 5 April 2016 at 22:30, Greg Mann  wrote:
> >
> > > +1 (non-binding)
> > >
> > > Ran `sudo make check` on CentOS 7 with libevent and SSL enabled; all
> > tests
> > > pass.
> > >
> > > I was also able to successfully simulate a simple upgrade scenario
> using
> > > 'test-upgrade.py'. Note that this initially failed due to some changes
> > made
> > > to the test framework in this release, but after applying this patch
> > >  the upgrade script succeeds.
> While
> > > ideally this patch for the upgrade script would be included in the
> > release,
> > > I don't consider it to be a blocker. If we end up cutting another RC,
> it
> > > would be great to include.
> > >
> > > Cheers,
> > > Greg
> > >
> > >
> > > On Tue, Apr 5, 2016 at 6:30 PM, Jie Yu  wrote:
> > >
> > > > Hi all,
> > > >
> > > > Please vote on releasing the following candidate as Apache Mesos
> > 0.28.1.
> > > >
> > > >
> > > > 0.28.1 includes the following bug fixes:
> > > >
> > > >
> > >
> >
> 
> > > >
> > > > [MESOS-4662] - PortMapping network isolator should not assume
> > > > BIND_MOUNT_ROOT is a realpath.
> > > > [MESOS-4874] - overlayfs does not work with kernel 4.2.3
> > > > [MESOS-4877] - Mesos containerizer can't handle top level docker
> image
> > > > like "alpine" (must use "library/alpine")
> > > > [MESOS-4878] - Task stuck in TASK_STAGING when docker fetcher failed
> to
> > > > fetch the image
> > > > [MESOS-4964] - curl based docker fetcher 

Re: [Isolation][Containerization] - Add Intel Cache Allocation Technology(CAT) Isolator Support

[Niklas Nielsen]

Suggesting Monday April 18 5pm PST - I will send out a hangout link when we
get closer. In the mean time, feel free to suggest agenda topics here:
https://docs.google.com/document/d/11mlGPZSABItP47J6VX-zB0fAK6Qr1mCIOI7nhlATMqk/edit#

Niklas

On Sun, Apr 10, 2016 at 8:27 PM, Du, Fan  wrote:

> 5:00 PM PST time is 8:00 AM on my timezone(UTC + 08:00)
> I think time slot after 5:00 PM PST will be ok for me.
>
> Thanks Nik!
>
>
> On 2016/4/9 6:11, Niklas Nielsen wrote:
>
>> Alright - with that in mind. Will morning, midday or evening PST be
>> preferred compared to your time zone?
>>
>


-- 
Niklas

Re: Accessibility For Mesos Web-GUI

[haosdent]

Hi, about "Mesos GUI do not have fully support Accessibility features", may
you provide more details? Does screen reader could not recognize the
contents in Mesos webui?

On Mon, Apr 11, 2016 at 10:10 PM, Andrew Li  wrote:

> Hello everyone:
>
> I find that Mesos GUI do not have fully support Accessibility features for
> disabled people to use the web GUI.
>
> For example:
>
> Web GUI can support screen reader to read page content for blind person.
> so we can fix some issues such as making Mesos Web GUI pages to support
> WAI-ARIA standard
> (https://www.w3.org/WAI/intro/aria)
>
> so How about my proposal?  need your comments.
>
> Thanks for all your help.
>



-- 
Best Regards,
Haosdent Huang

Re: Design doc: ordered delivery in libprocess

[Neil Conway]

Hi all,

It turns out this design doesn't work. The reason is that we made the
following assumption: given a client like:

s1 = connect(); send(s1, "msg1"); close(s1);
s2 = connect(); send(s2, "msg2"); close(s2);

And a server like:

char buf[...];
while (true) {
  s = accept();
  recv(s, buf);
  close(s);
}

Our design required that the server-side socket corresponding to "s1"
would always be accepted _before_ the server-side socket for "s2".
That is, that we can rely on the order in which server-side sockets
are accept()'d to infer the order in which client-side sockets are
connect()'d, as long as the client only makes at most one connect() to
a given host at a given time.

It turns out that this isn't the case on either OSX or Linux. I
haven't dug too deeply into the reasons why, but one plausible
explanation is that the kernel is using multiple accept() queues and
dispatching inbound connections to a queue in some unpredictable way.

It seems that implementing ordered delivery will require adding
metadata to the libprocess socket-establishment protocol to give the
recipient enough information to determine which of the inbound
connections from a given libprocess instance is the "newest".

Neil


On Fri, Mar 25, 2016 at 12:50 PM, Neil Conway  wrote:
> A few months ago, there was a dev list thread on whether libprocess
> should provide ordered delivery [1]. The consensus then was that
> libprocess doesn't provide ordered delivery in a few corner cases, but
> that we should fix that behavior to guarantee ordered (but unreliable)
> message delivery.
>
> Please see this design doc for a proposal of how to achieve this:
>
> https://docs.google.com/document/d/1oqv42-GYXfh0TsyXGCBhxakXw8ckXMCnEb0T-ydEyYM/edit#
>
> Comments welcome.
>
> Thanks,
> Neil
>
> [1] 
> https://mail-archives.apache.org/mod_mbox/mesos-dev/201511.mbox/%3CCAOW5sYaANyaRD-Mbk7E_VsWwF=xrtcvhszuvmunj4sq8jdt...@mail.gmail.com%3E

Accessibility For Mesos Web-GUI

[Andrew Li]

Hello everyone:

I find that Mesos GUI do not have fully support Accessibility features for
disabled people to use the web GUI.

For example:

Web GUI can support screen reader to read page content for blind person.
so we can fix some issues such as making Mesos Web GUI pages to support
WAI-ARIA standard
(https://www.w3.org/WAI/intro/aria)

so How about my proposal?  need your comments.

Thanks for all your help.

Re: On launching command tasks

[Alex Rukletsov]

Connor,

this is also fine and improves current behaviour.

On Sat, Apr 9, 2016 at 10:52 PM,  wrote:

> Hi Alex, inline.
>
> > On Apr 9, 2016, at 12:00, Alex Rukletsov  wrote:
> >
> > if `shell` is false and `argv.size` is
> > 0, assign command to `argv[0]`?
>
> Instead of trying to fix the TaskInfo on behalf of the framework, maybe it
> would be more transparent to preemptively fail the task with TASK_ERROR in
> this case?
>
> > On Sat, Apr 9, 2016 at 2:59 AM, Benjamin Mahler 
> wrote:
> >
> >>>
> >>> Mesos expects the first argument to be the same
> >>> as the command itself [1]
> >>
> >>
> >> To be precise, what does "expect" mean here? Do we actually have code in
> >> mesos with this expectation? Or are you just saying that we require
> >> CommandInfo.arguments to map directly to exec's 'args'?
> >>
> >> Have you considered why exec has this API? It looks like there are some
> use
> >> cases for not just using the filename as argv[0]?
> >>
> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
> (see
> >> Rationale)
> >>
> >>> The requirement on a Strictly Conforming POSIX Application also states
> >>> that the value passed as the first argument be a filename string
> >> associated
> >>> with the process being started. Although some existing applications
> pass
> >> a
> >>> pathname rather than a filename string in some circumstances, a
> filename
> >>> string is more generally useful, since the common usage of argv[0] is
> in
> >>> printing diagnostics. In some cases the filename passed is not the
> actual
> >>> filename of the file; for example, many implementations of the login
> >>> utility use a convention of prefixing a  ( '-' ) to the actual
> >>> filename, which indicates to the command interpreter being invoked that
> >> it
> >>> is a "login shell".
> >>
> >>
> >>> On Sat, Apr 2, 2016 at 7:14 AM, Guangya Liu 
> wrote:
> >>>
> >>> +1 on using docker mode, this can help the framework developer.
> >>>
> >>> Setting the command twice can sometimes make people confused. When I
> was
> >>> working for the patch https://reviews.apache.org/r/1/ , I was
> also a
> >>> bit confused before go through the code in agent part.
> >>>
> >>>
> >>>
>  On Sat, Apr 2, 2016 at 1:17 AM, haosdent  wrote:
> 
>  +1 For follow Docker behaviour, it is inconvenient to write the
> command
>  twice.
> 
>  On Fri, Apr 1, 2016 at 10:12 PM, Alex Rukletsov 
>  wrote:
> 
> > When launching a command task without wrapping it in `/bin/sh -c`
> >> (i.e.
> > CommandInfo.shell=false), Mesos expects the first argument to be the
> >>> same
> > as the command itself [1]. Though this is similar to how UNIX exec*
> >>> calls
> > operate, it can be unclear to a user. Moreover, we do not validate
> >> this
>  on
> > the master side, but rather let the command executor crash with a
> >> "bad
> > address" error. Docker, for example, requires the command only once
> >> in
> > their entrypoint specification [2].
> >
> > My suggestion is to change the command executor so that it ensures
> >> that
>  the
> > first argument is always the command itself.
> >
> > Alternatively, if we prefer to keep the current behaviour, I would
>  propose
> > to adjust the documentation to be more explicit and introduce a
>  validation
> > check on the master.
> >
> > [1] Example snippet in C++
> >
> >   commandInfo->set_value(command);
> >
> >   commandInfo->add_arguments()->assign(command);
> >
> >
> > [2] https://docs.docker.com/engine/reference/builder/#entrypoint
> 
> 
> 
>  --
>  Best Regards,
>  Haosdent Huang
> >>
>

Re: Design Doc for Qemu/KVM containerizer

[Vaibhav Khanduja]

+1 

lkvm should be taken as a separate activity ..prioritized based on it maturity 
.. 




On 4/11/16, 1:08 PM, "Du, Fan"  wrote:

>Thanks to bring *heavy* container to Mesos :)
>I have a few comments as below:
>
>1.
>One of reason adding Qemu/KVM is to support scenario where end user env 
>must be based on Windows,
>while as we know Mesos also support Windows Server, if framework user 
>knows there is native Windows
>based container present, there wouldn't need Qemu/KVM to support this. 
>So for efficiency, the question
>(maybe off the topic already) is how/should to make this transparent to 
>framework user here?
>
>if mesos has native container based on Windows, then use it. Otherwise 
>use Windows spawned by Qemu/KVM.
>
>2.
>There is MESOS-5163 to support LKVM Containerization, lkvm is just a 
>toy(learning vehicle) for virtualization,
>it also does not have proven-record for production use cases, moreover 
>it has few community attention(search
>kvm mail list). After Intel announced Clear Container, it has been hold 
>by ARM,please don't add lkvm here
>unless you have compelling reason to do so.
>
>
>On 2016/4/7 20:34, Abhishek Dasgupta wrote:
>> Hi all,
>>
>> I uploaded a design doc for Mesos-2717:
>>
>> https://docs.google.com/document/d/1_VuFiJqxjlH_CA1BCMknl3sadlTZ69FuDe7qasDIOk0/edit?usp=sharing
>>
>>
>> Need your views and comments on it.
>>

Re: Design Doc for Qemu/KVM containerizer

[Du, Fan]

Thanks to bring *heavy* container to Mesos :)
I have a few comments as below:

1.
One of reason adding Qemu/KVM is to support scenario where end user env 
must be based on Windows,
while as we know Mesos also support Windows Server, if framework user 
knows there is native Windows
based container present, there wouldn't need Qemu/KVM to support this. 
So for efficiency, the question
(maybe off the topic already) is how/should to make this transparent to 
framework user here?


if mesos has native container based on Windows, then use it. Otherwise 
use Windows spawned by Qemu/KVM.


2.
There is MESOS-5163 to support LKVM Containerization, lkvm is just a 
toy(learning vehicle) for virtualization,
it also does not have proven-record for production use cases, moreover 
it has few community attention(search
kvm mail list). After Intel announced Clear Container, it has been hold 
by ARM,please don't add lkvm here

unless you have compelling reason to do so.


On 2016/4/7 20:34, Abhishek Dasgupta wrote:

Hi all,

I uploaded a design doc for Mesos-2717:

https://docs.google.com/document/d/1_VuFiJqxjlH_CA1BCMknl3sadlTZ69FuDe7qasDIOk0/edit?usp=sharing


Need your views and comments on it.