Re: Work group on Community

[James Peach]

> On Jun 15, 2017, at 10:57 AM, Vinod Kone  wrote:
> 
> Hi folks,
> 
> Seeing that our first official containerizer WG is off to a good start, we
> want to use that momentum to start new WGs.
> 
> I'm proposing that we start a new work group on community. The mission of
> this work group would be to figure out ways to grow the size of our
> community and improve the experience of community members (users, devs,
> contributors, committers etc).
> 
> In the first meeting, we can nail down what the charter of this work group
> should be etc. My initial ideas for the topics/components this work group
> could cover
> 
> --> Releases
> --> Roadmap
> --> Reviews
> --> JIRA
> --> CI
> 
> Over time, I'm hoping that new specific work groups will sprung up that can
> own some of these topics.
> 
> If you are interested in joining this work group, please reply to this
> thread and I'll add you to the invite.

I'm interested, but unlikely to have much bandwidth to contribute anything 
substantial. One suggestion I have is that a Mesos Weekly news would be pretty 
great. There is a lot of activity on reviewboard, slack and in design documents 
and collecting that in a regular newsletter would give that activity a lot more 
visibility.

J

Re: Work group on Community

[Jake Farrell]

I would be happy to join in on this initiative and do what I can to help

-Jake

On Thu, Jun 15, 2017 at 1:57 PM, Vinod Kone  wrote:

> Hi folks,
>
> Seeing that our first official containerizer WG is off to a good start, we
> want to use that momentum to start new WGs.
>
> I'm proposing that we start a new work group on community. The mission of
> this work group would be to figure out ways to grow the size of our
> community and improve the experience of community members (users, devs,
> contributors, committers etc).
>
> In the first meeting, we can nail down what the charter of this work group
> should be etc. My initial ideas for the topics/components this work group
> could cover
>
> --> Releases
> --> Roadmap
> --> Reviews
> --> JIRA
> --> CI
>
> Over time, I'm hoping that new specific work groups will sprung up that can
> own some of these topics.
>
> If you are interested in joining this work group, please reply to this
> thread and I'll add you to the invite.
>
> Thanks,
> Vinod
>

Re: Welcome Greg Mann as a new committer and PMC member!

[Zhitao Li]

Congratulations, Greg! It's such a pleasure to work with you, and special
thanks for all the effort on the security aspect of Mesos.

On Thu, Jun 15, 2017 at 4:12 PM, Benjamin Mahler  wrote:

> Thanks for all that you've done for the project so far Greg, it's been a
> pleasure working with you.
>
> Congrats and welcome!
>
> On Tue, Jun 13, 2017 at 2:42 PM, Vinod Kone  wrote:
>
> > Hi folks,
> >
> > Please welcome Greg Mann as the newest committer and PMC member of the
> > Apache Mesos project.
> >
> > Greg has been an active contributor to the Mesos project for close to 2
> > years now and has made many solid contributions. His biggest source code
> > contribution to the project has been around adding authentication support
> > for default executor. This was a major new feature that involved quite a
> > few moving parts. Additionally, he also worked on improving the scheduler
> > and executor APIs.
> >
> > Here is his more formal checklist for your perusal.
> >
> > https://docs.google.com/document/d/1S6U5OFVrl7ySmpJsfD4fJ3_
> > R8JYRRc5spV0yKrpsGBw/edit
> >
> > Thanks,
> > Vinod
> >
> >
>



-- 
Cheers,

Zhitao Li

Re: [Proposal] Multiple Containers in Single Mesos Task

[Zhitao Li]

Hi Ben,

Thanks for reading the proposal. There are several motivations, although
scalability is the primary one:

1) w.r.t. scalability, it's not only Mesos's own scalability, but also many*
additional infra tools* which need to integrate with Mesos and process
*every* task in the cluster: a 2-3x increase on task numbers would easily
make these systems harder to catch up with cluster size;
2) Another thing we are looking at is to provide more robust and powerful
upgrade story for a pod of containers. Although such work does not demand
modeling multiple containers to one task, our internal discussions feel
that this modeling makes it easier to handle. A couple of things we are
specifically looking at:

   - reliable in-place upgrade: while dynamic reservation usually works,
   it's still non-trivial to provide exact guarantee that allocator/master
   will send back offers after a `KILL` in time. This is technically more
   related to MESOS-1280 .
   - automatic rollback upon failed upgrade: similar to above point, it'll
   be great if the entire scheduler/mesos stack can guarantee an atomic
   rollback. Right now this depends on availability of entire control plane
   (scheduler and master) since multiple messages need to be passed.
   - zero-traffic-loss upgrade: if workload utilizes primitives like
   SO_REUSE_PORT , it should be possible
   to upgrade a container w/o losing any customer traffic.

3) another awkwardness of TaskGroup is that we do not really know how to
proper size a task within a group because they are isolated by the same
root container's scope, neither do we really care from a scheduler's
perspective. Sizing the sum of the containers are far more important than
sizing each task to us.
4) Also, it seems like we cannot add a new "zero resource usage" task to a
group right now, therefore adding/removing a container has to involved both
the "scheduling" logic, and the "container upgrade" part.

The last two points came from internal discussion with our scheduler team.
I guess they may not be as significant as first two, but I'm just putting
them on the table.


On Thu, Jun 15, 2017 at 2:43 PM, Benjamin Mahler  wrote:

> From reading this, the motivation is that TaskGroup having 1 task per
> container "could create a scalability issue for a large scale Mesos cluster
> since many endpoints/operations scale with the total number of Tasks in the
> cluster."
>
> Is that the only motivation here?
>
> On Thu, Jun 15, 2017 at 11:45 AM, Charles Raimbert 
> wrote:
>
>> Hello All,
>>
>> As we are interested in PODs to run colocated containers under the same
>> grouping, we have been looking at TaskGroup but we have also been working
>> on a design to allow multiple containers in the same Task.
>>
>> Please feel free to write your comments and suggestions on the proposal
>> draft:
>> https://docs.google.com/document/d/1Os5tXUJfJ8Op_YBZR7L8hSHq
>> IeO1f9LY2yzKxsOdrwg
>>
>> Thanks,
>> Charles Raimbert & Zhitao Li
>>
>
>


-- 
Cheers,

Zhitao Li