hi zhitao, in task definition, on task only one instance, you introduce multiple containers it broke the defined convention, need more committer comments.
2017-06-19 23:46 GMT+08:00 Zhitao Li <zhitaoli...@gmail.com>: > Hi Tommy, > > Are you suggesting to either replace Task with Pod, or adding a new concept > of Pod? Former would be too destructive to users and I don't see enough > value. For adding new concept of pod: task has reliable status update and > are modeled all around in Mesos and I feel doing that for another level of > concept is not worth it. > > On Sun, Jun 18, 2017 at 10:18 PM, tommy xiao <xia...@gmail.com> wrote: > > > it looks like Pod. how about upgrade TASK to POD concept? > > > > 2017-06-16 23:57 GMT+08:00 Zhitao Li <zhitaoli...@gmail.com>: > > > > > 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 <https://issues.apache.org/ > > jira/browse/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 <https://lwn.net/Articles/542629/>, 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 <bmah...@apache.org> > > > 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 < > > > craimber...@gmail.com> > > > > 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 > > > > > > > > > > > -- > > Deshi Xiao > > Twitter: xds2000 > > E-mail: xiaods(AT)gmail.com > > > > > > -- > Cheers, > > Zhitao Li > -- Deshi Xiao Twitter: xds2000 E-mail: xiaods(AT)gmail.com
