Re: Apache Mesos Logo for MesosCon Stickers

[Sharan Foga]

Hi Tomek

Thanks for the response. The main thing I need is just a pdf version of the 
Mesos logo. I do a lot of the ordering on behalf of the ASF for stickers and 
promotional giveaways for Apache events such as ApacheCon. As the ASF will be 
having a booth at MesosCon Europe I'd like to have some Mesos stickers 
available to give away.

We already have an approved sticker supplier and any printing costs will be 
covered by the ASF Marketing & Publicity budget.

Thanks
Sharan

On 2017-10-09 16:13, Tomek Janiszewski  wrote: 
> Hi
> 
> I described the process of ordering Mesos Stickers here
> https://lists.apache.org/thread.html/932f8fd677ca5c1520e843f2166fbd76bc6bb3d603bd864aedb5eeed@%3Cuser.mesos.apache.org%3E
> 
> Best
> Tomek
> 
> pon., 9 paź 2017 o 16:01 użytkownik Sharan Foga  
> napisał:
> 
> > Hi
> >
> > My name is Sharan. I'm involved with Apache Community Development and I'll
> > be running the Apache Software Foundation booth at MesosCon Europe in
> > Prague in a few weeks. The plan is to give away project stickers and
> > various ASF swag – so if you are coming along then please feel free to 
> > drop
> > by, say hello and pick something up.
> >
> > I'm currently in the process of ordering some more stickers and am looking
> > for the Apache Mesos logo to get some printed. Please can anyone tell me
> > (or send me a link to) where I can find the Apache Mesos logo artwork?
> >
> > Thanks
> > Sharan
> >
> 

Re: Adding the limited resource to TaskStatus messages

[Wil Yegelwel]

Is it correct to say that the limited resource field is *only* meant to
provide machine readable information about what resources limits were
exceeded?

If so, does it make sense to provide richer reporting fields for all
failure reasons? I imagine other failure reasons could benefit from being
able to report details of the failure that are machine readable.

On Mon, Oct 9, 2017, 3:50 PM James Peach  wrote:

>
> > On Oct 9, 2017, at 1:27 PM, Vinod Kone  wrote:
> >
> >> In the case that a task is killed because it violated a resource
> >> constraint (ie. the reason field is REASON_CONTAINER_LIMITATION,
> >> REASON_CONTAINER_LIMITATION_DISK or REASON_CONTAINER_LIMITATION_MEMORY),
> >> this field may be populated with the resource that triggered the
> >> limitation. This is intended to give better information to schedulers
> about
> >> task resource failures, in the expectation that it will help them bubble
> >> useful information up to the user or a monitoring system.
> >>
> >
> > Can you elaborate what schedulers are expected to do with this
> information?
> > Looking for some concrete use cases if you can.
>
> There's no concrete use case here; it's just a matter of propagating
> information we know in a structured way.
>
> If we assume that the scheduler knows about some sort of monitoring system
> or has a UI, we can present this to the user or a system that can take
> action on it. The status quo is that the raw message string is dumped to
> logs, and has to be manually interpreted.
>
> Additionally, this can pave the way to getting rid of
> REASON_CONTAINER_LIMITATION_DISK and REASON_CONTAINER_LIMITATION_MEMORY.
> All you really need is REASON_CONTAINER_LIMITATION plus the resource
> information.
>
> J
>
>

Re: Updating running tasks in-place

[Yan Xu]

---
Jiang Yan Xu  | @xujyan 

On Wed, Oct 4, 2017 at 11:50 AM, Zhitao Li  wrote:

> Thanks for taking the lead, Yan! Replying to your points inline:
>
> On Wed, Oct 4, 2017 at 11:11 AM, Yan Xu  wrote:
>
> > Hi Mesos users/devs,
> >
> > I am curious about what use cases do folks in the community have about
> > updating running tasks? i.e., amending the current task without going
> > through the typical kill -> offer -> relaunch process.
> >
> > Typically you would only want to do that for the "pets
> > "
> > in
> > your cluster as it adds complexity in managing the tasks' lifecycle but
> > nevertheless in some cases it is too expensive to relocate the app or
> even
> > relaunching it onto the same host later.
> >
> > https://issues.apache.org/jira/browse/MESOS-1280 has some context about
> > this. In particular, people have mentioned the desire to:
> >
> >- Dynamically reconfiguring the task without restarting it.
> >- Upgrading the task transparently (i.e., restarting without dropping
> >connections)
> >
>
> One possible use case we have on this is to upgrade service mesh components
> (consider something similar to haproxy): because these instances handles
> all connections on the machine, restarting without dropping connection is a
> must for them.
>
>
Yeah this is an interesting. Sometime like this
 or
SO_REUSEPORT
like you've mentioned before right? Seems like this would require a period
of time where both processes are running inside the pod and connections are
gradually drained from the old process and established on the new process?
Have already made it work outside of Mesos or on Mesos as separate tasks?


> >- Replacing tasks with another without going through offer cycles
> >
>
> We have concrete use case for this one.
>
>
> >- Task resizing 
> > (which
> >is captured in another JIRA)
>
>- Certain metadata, e.g., labels (but I imagine not all metadata makes
> >equal sense to be updatable).
> >
> > What other/specific use cases are folks interested in?
> >
> > Best,
> > Yan
> >
>
>
>
> --
> Cheers,
>
> Zhitao Li
>

Re: Adding the limited resource to TaskStatus messages

[James Peach]

> On Oct 9, 2017, at 1:27 PM, Vinod Kone  wrote:
> 
>> In the case that a task is killed because it violated a resource
>> constraint (ie. the reason field is REASON_CONTAINER_LIMITATION,
>> REASON_CONTAINER_LIMITATION_DISK or REASON_CONTAINER_LIMITATION_MEMORY),
>> this field may be populated with the resource that triggered the
>> limitation. This is intended to give better information to schedulers about
>> task resource failures, in the expectation that it will help them bubble
>> useful information up to the user or a monitoring system.
>> 
> 
> Can you elaborate what schedulers are expected to do with this information?
> Looking for some concrete use cases if you can.

There's no concrete use case here; it's just a matter of propagating 
information we know in a structured way.

If we assume that the scheduler knows about some sort of monitoring system or 
has a UI, we can present this to the user or a system that can take action on 
it. The status quo is that the raw message string is dumped to logs, and has to 
be manually interpreted. 

Additionally, this can pave the way to getting rid of 
REASON_CONTAINER_LIMITATION_DISK and REASON_CONTAINER_LIMITATION_MEMORY. All 
you really need is REASON_CONTAINER_LIMITATION plus the resource information.

J

Re: Adding the limited resource to TaskStatus messages

[Vinod Kone]

> In the case that a task is killed because it violated a resource
> constraint (ie. the reason field is REASON_CONTAINER_LIMITATION,
> REASON_CONTAINER_LIMITATION_DISK or REASON_CONTAINER_LIMITATION_MEMORY),
> this field may be populated with the resource that triggered the
> limitation. This is intended to give better information to schedulers about
> task resource failures, in the expectation that it will help them bubble
> useful information up to the user or a monitoring system.
>

Can you elaborate what schedulers are expected to do with this information?
Looking for some concrete use cases if you can.

Re: organizing a "docathon"

[Benjamin Hindman]

Please see this doc

for more details as well as ideas for documentation. Please add more
yourself!


On Wed, Oct 4, 2017 at 6:19 PM Benjamin Hindman 
wrote:

> We've decided on Thursday 10/12!
>
> If you're interested in joining us in person in San Francisco please reply
> just to me.
>
> Stay tuned for more details. Looking forward!
>
> On Mon, Oct 2, 2017 at 6:05 PM Benjamin Hindman <
> benjamin.hind...@gmail.com> wrote:
>
>> Pinging this thread just to remind folks to sign up, thank you!
>>
>> On Mon, Sep 25, 2017 at 4:09 PM Benjamin Hindman <
>> benjamin.hind...@gmail.com> wrote:
>>
>>> Some folks have expressed interest in an organized documentation
>>> hackathon, aka "docathon".
>>>
>>> We'll make this something people can participate in remotely, but we'll
>>> also provide space (TBD, most likely at Mesosphere in San Francisco) for
>>> the first one of these for anyone that would like to join in person.
>>>
>>> Basic agenda will be for folks to get together to discuss where docs can
>>> be improved, then break into teams to work on improving the docs, then come
>>> back together for food/drinks and presentations on how we improved the docs
>>> along with some prizes!
>>>
>>> If you're interested in joining, please fill out this poll
>>> .
>>>
>>> Looking forward to improving the docs with everyone!
>>>
>>

Re: Adding the limited resource to TaskStatus messages

[Jie Yu]

+1

On Mon, Oct 9, 2017 at 10:56 AM, James Peach  wrote:

> Hi all,
>
> In https://reviews.apache.org/r/62644/, I am proposing to add an optional
> Resources field to the TaskStatus message named `limited_resources`.
>
> In the case that a task is killed because it violated a resource
> constraint (ie. the reason field is REASON_CONTAINER_LIMITATION,
> REASON_CONTAINER_LIMITATION_DISK or REASON_CONTAINER_LIMITATION_MEMORY),
> this field may be populated with the resource that triggered the
> limitation. This is intended to give better information to schedulers about
> task resource failures, in the expectation that it will help them bubble
> useful information up to the user or a monitoring system.
>
> diff --git a/include/mesos/v1/mesos.proto b/include/mesos/v1/mesos.proto
> index d742adbbf..559d09e37 100644
> --- a/include/mesos/v1/mesos.proto
> +++ b/include/mesos/v1/mesos.proto
> @@ -2252,6 +2252,13 @@ message TaskStatus {
>// status updates for tasks running on agents that are unreachable
>// (e.g., partitioned away from the master).
>optional TimeInfo unreachable_time = 14;
> +
> +  // If the reason field indicates a container resource limitation,
> +  // this field contains the resource whose limits were violated.
> +  //
> +  // NOTE: 'Resources' is used here because the resource may span
> +  // multiple roles (e.g. `"mem(*):1;mem(role):2"`).
> +  repeated Resource limited_resources = 16;
>  }
>
>
>
> cheers,
> James
>
>
>

Re: Adding the limited resource to TaskStatus messages

[Yan Xu]

Does it make sense to wrap the resources in a `Limitation` message in case
we add new fields for it?

---
Jiang Yan Xu  | @xujyan 

On Mon, Oct 9, 2017 at 10:56 AM, James Peach  wrote:

> Hi all,
>
> In https://reviews.apache.org/r/62644/, I am proposing to add an optional
> Resources field to the TaskStatus message named `limited_resources`.
>
> In the case that a task is killed because it violated a resource
> constraint (ie. the reason field is REASON_CONTAINER_LIMITATION,
> REASON_CONTAINER_LIMITATION_DISK or REASON_CONTAINER_LIMITATION_MEMORY),
> this field may be populated with the resource that triggered the
> limitation. This is intended to give better information to schedulers about
> task resource failures, in the expectation that it will help them bubble
> useful information up to the user or a monitoring system.
>
> diff --git a/include/mesos/v1/mesos.proto b/include/mesos/v1/mesos.proto
> index d742adbbf..559d09e37 100644
> --- a/include/mesos/v1/mesos.proto
> +++ b/include/mesos/v1/mesos.proto
> @@ -2252,6 +2252,13 @@ message TaskStatus {
>// status updates for tasks running on agents that are unreachable
>// (e.g., partitioned away from the master).
>optional TimeInfo unreachable_time = 14;
> +
> +  // If the reason field indicates a container resource limitation,
> +  // this field contains the resource whose limits were violated.
> +  //
> +  // NOTE: 'Resources' is used here because the resource may span
> +  // multiple roles (e.g. `"mem(*):1;mem(role):2"`).
> +  repeated Resource limited_resources = 16;
>  }
>
>
>
> cheers,
> James
>
>
>

Adding the limited resource to TaskStatus messages

[James Peach]

Hi all,

In https://reviews.apache.org/r/62644/, I am proposing to add an optional 
Resources field to the TaskStatus message named `limited_resources`.

In the case that a task is killed because it violated a resource constraint 
(ie. the reason field is REASON_CONTAINER_LIMITATION, 
REASON_CONTAINER_LIMITATION_DISK or REASON_CONTAINER_LIMITATION_MEMORY), this 
field may be populated with the resource that triggered the limitation. This is 
intended to give better information to schedulers about task resource failures, 
in the expectation that it will help them bubble useful information up to the 
user or a monitoring system.

diff --git a/include/mesos/v1/mesos.proto b/include/mesos/v1/mesos.proto
index d742adbbf..559d09e37 100644
--- a/include/mesos/v1/mesos.proto
+++ b/include/mesos/v1/mesos.proto
@@ -2252,6 +2252,13 @@ message TaskStatus {
   // status updates for tasks running on agents that are unreachable
   // (e.g., partitioned away from the master).
   optional TimeInfo unreachable_time = 14;
+
+  // If the reason field indicates a container resource limitation,
+  // this field contains the resource whose limits were violated.
+  //
+  // NOTE: 'Resources' is used here because the resource may span
+  // multiple roles (e.g. `"mem(*):1;mem(role):2"`).
+  repeated Resource limited_resources = 16;
 }



cheers,
James

Re: Apache Mesos Logo for MesosCon Stickers

[Tomek Janiszewski]

Hi

I described the process of ordering Mesos Stickers here
https://lists.apache.org/thread.html/932f8fd677ca5c1520e843f2166fbd76bc6bb3d603bd864aedb5eeed@%3Cuser.mesos.apache.org%3E

Best
Tomek

pon., 9 paź 2017 o 16:01 użytkownik Sharan Foga  napisał:

> Hi
>
> My name is Sharan. I'm involved with Apache Community Development and I'll
> be running the Apache Software Foundation booth at MesosCon Europe in
> Prague in a few weeks. The plan is to give away project stickers and
> various ASF swag – so if you are coming along then please feel free to drop
> by, say hello and pick something up.
>
> I'm currently in the process of ordering some more stickers and am looking
> for the Apache Mesos logo to get some printed. Please can anyone tell me
> (or send me a link to) where I can find the Apache Mesos logo artwork?
>
> Thanks
> Sharan
>

Apache Mesos Logo for MesosCon Stickers

[Sharan Foga]

Hi 

My name is Sharan. I'm involved with Apache Community Development and I'll be 
running the Apache Software Foundation booth at MesosCon Europe in Prague in a 
few weeks. The plan is to give away project stickers and various ASF swag – 
so if you are coming along then please feel free to drop by, say hello and pick 
something up.

I'm currently in the process of ordering some more stickers and am looking for 
the Apache Mesos logo to get some printed. Please can anyone tell me (or send 
me a link to) where I can find the Apache Mesos logo artwork?

Thanks
Sharan

Fwd: Singularity failing to create Mesos slave on Rancher with RHEL 7 instances

[Milindu Sanoj Kumarage]

Hi all,

I'm trying to deploy Singularity (
which is a scheduler for running Mesos tasks ) on Rancher with a set of
RHEL 7.3 (3.10.0) instances. Everything else works fine but the slave node
keeps failing to start giving the following error.


10/9/2017 1:26:37 PMFailed to create a containerizer: Could not create
> MesosContainerizer: Failed to create launcher: Failed to create Linux
> launcher: Failed to determine the hierarchy where the subsystem freezer is
> attached
> 10/9/2017 1:27:37 PMI1009 07:57:37.437608 1 main.cpp:223] Build:
> 2016-04-14 15:41:24 by root
> 10/9/2017 1:27:37 PMI1009 07:57:37.437958 1 main.cpp:225] Version:
> 0.28.1
> 10/9/2017 1:27:37 PMI1009 07:57:37.437963 1 main.cpp:228] Git tag:
> 0.28.1
> 10/9/2017 1:27:37 PMI1009 07:57:37.437968 1 main.cpp:232] Git SHA:
> 555db235a34afbb9fb49940376cc33a66f1f85f0
> 10/9/2017 1:27:37 PMMount failed for selinuxfs on /sys/fs/selinux:
>  Operation not permitted
> 10/9/2017 1:27:37 PMI1009 07:57:37.564023 1 containerizer.cpp:149]
> Using isolation: cgroups/cpu,cgroups/mem,filesystem/posix



I'm using the docker-compose.yml

file in the Singularity repo  to
deploy to Rancher. When I queried about this issue
, I was told this is
something wrong with the configuration of mesos slave, How can I resolve
this?

PS: I raised this

question on Stackoverflow also, but did not get any answer.


Regards,
Milindu Sanoj Kumarage
LinkedIn  | GitHub
 | agentmilindu.com