[GitHub] mesos pull request #239: Added Nathan Jackson to contributors list.
GitHub user nathanjackson opened a pull request: https://github.com/apache/mesos/pull/239 Added Nathan Jackson to contributors list. Following the directions here: http://mesos.apache.org/documentation/latest/submitting-a-patch/ I'd like to get involved writing patches. You can merge this pull request into a Git repository by running: $ git pull https://github.com/nathanjackson/mesos new-contributor Alternatively you can review and apply these changes as the patch at: https://github.com/apache/mesos/pull/239.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #239 commit 4bf066d78ce10a80b808c2916b3ea9760969d47d Author: Nathan Jackson Date: 2017-10-06T03:18:13Z Added Nathan Jackson to contributors list. ---
[GitHub] mesos pull request #238: Added Gitential and Lensa to powered-by
Github user asfgit closed the pull request at: https://github.com/apache/mesos/pull/238 ---
Re: Chained CNI plugin support
Hi Michael,
Deepak (cced) has volunteered to work on this. I am doubtful this will get
done in the 1.5 time frame. I am hoping we can make this happen in the 1.6
time frame.
-Avinash
On Thu, Oct 5, 2017 at 11:08 AM, Michael Cambria
wrote:
>
> Which version of mesos will support CNI Plugin Chaining?
>
> Specifically, when will I have the ability to use my own custom plugin(s)
> and/or CNI supplied tuning plugin(s) chained with CNI supplied plugin such
> as bridge and host-local?
>
> An example conflist added to /etc/cni/net.d/chain0.conflist is below. The
> bridge and host-local and tuning plugins come from CNI plugins repo, and
> "mychain" is something we supply. This works with cnitool, need it to work
> with mesos asap.
>
>
> {
> "name": "chain0",
> "cniVersion": "0.3.1",
> "plugins": [
> {
> "type": "bridge",
> "bridge": "mynet",
> "ipMasq": true,
> "isGateway": true,
> "ipam": {
> "type": "host-local",
> "subnet": "10.10.10.0/24",
> "routes": [
> { "dst": "0.0.0.0/0" }
> ]
> }
> },
> {
> "name": "mytuning",
> "type": "tuning",
> "sysctl": {
> "net.core.somaxconn": "500"
> }
> },
> {
>"type": "chain0",
>"Chain0_Flag": true,
>"Chain0_Arg": "Arg0"
> }
> ]
> }
>
>
>
--
Avinash Sridharan, Mesosphere
+1 (323) 702 5245
Chained CNI plugin support
Which version of mesos will support CNI Plugin Chaining?
Specifically, when will I have the ability to use my own custom
plugin(s) and/or CNI supplied tuning plugin(s) chained with CNI supplied
plugin such as bridge and host-local?
An example conflist added to /etc/cni/net.d/chain0.conflist is below.
The bridge and host-local and tuning plugins come from CNI plugins repo,
and "mychain" is something we supply. This works with cnitool, need it
to work with mesos asap.
{
"name": "chain0",
"cniVersion": "0.3.1",
"plugins": [
{
"type": "bridge",
"bridge": "mynet",
"ipMasq": true,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.10.10.0/24",
"routes": [
{ "dst": "0.0.0.0/0" }
]
}
},
{
"name": "mytuning",
"type": "tuning",
"sysctl": {
"net.core.somaxconn": "500"
}
},
{
"type": "chain0",
"Chain0_Flag": true,
"Chain0_Arg": "Arg0"
}
]
}
Re: [Containerization WG] Meeting tomorrow
Janardhan, the data the timezone information is in the agenda/notes doc: https://docs.google.com/document/d/1z55a7tLZFoRWVuUxz1FZwgxkHeugtc2nHR89skFXSpU/edit#heading=h.msd2k954ikcq There is a link to the invite in the doc. - Jie On Thu, Oct 5, 2017 at 10:47 AM, Janardhan Pulivarthi < janardhan.pulivar...@gmail.com> wrote: > Hi Jie, > > can you please provide the date & time both, because we're in different > timezones. > > Thanks, > Janardhan > > On Thu, Oct 5, 2017 at 5:14 AM, Jie Yu wrote: > > > Hi > > > > We'll have our regular sync tomorrow morning at 9am PST. Zhitao and > Gilbert > > will be chatting about the docker image gc support they've been working > on. > > > > There is the full agenda and notes. Feel free to add more! > > https://docs.google.com/document/d/1z55a7tLZFoRWVuUxz1FZwgxkHeugt > > c2nHR89skFXSpU/edit?usp=sharing > > > > See you all tomorrow morning! > > > > - Jie > > >
Re: [Containerization WG] Meeting tomorrow
Hi Jie, can you please provide the date & time both, because we're in different timezones. Thanks, Janardhan On Thu, Oct 5, 2017 at 5:14 AM, Jie Yu wrote: > Hi > > We'll have our regular sync tomorrow morning at 9am PST. Zhitao and Gilbert > will be chatting about the docker image gc support they've been working on. > > There is the full agenda and notes. Feel free to add more! > https://docs.google.com/document/d/1z55a7tLZFoRWVuUxz1FZwgxkHeugt > c2nHR89skFXSpU/edit?usp=sharing > > See you all tomorrow morning! > > - Jie >
Re: Shedding light on libmesos and libprocess threading models?
Hi, Sorry this has taken over a week to get back! I'm still getting loads of threads as before and I've now double checked my Makefile and the output of ldd. I am only explicitly linking against libmesos and libomp5. I see that libmesos itself links against a ton of other libraries, which is fine, but my problem still holds; it seems that in a function that makes use of an OMP parallel for creates a thread pool of N every time it is called by a different Mesos worker thread? Eg. I end up with 64 threads instead of 8. I gather there is little I can do to prevent this? Not in any easy way!? I guess it'll have to be some global variable and one-time explicit initialisation of the (OMP) pool rather than a thread-local/stack variable, which is how a more straight-forward use of OMP would work. Anyway, I guess this isn't a Mesos problem - just a clash of worker pools! Just wanted some insight into the (Mesos) thread model to be sure. Cheers, Jim On 26 September 2017 at 11:18, James Vanns wrote: > Oh!? Hmm. I'll take a look - I wasn't explicitly linking against anything > uncommon other than libomp and libmesos/libprocess. I'll see what ldd says! > > Jim > > > On 26 September 2017 at 11:07, Benno Evers wrote: > >> Hi Jim, >> >> I think how the additional threads are used depends on what else your >> binary is linked against, for example if I set >> LIBPROCESS_NUM_WORKER_THREADS=4 on my local mesos-master, I get a process >> with 7 threads, of which are: >> >> - 1 "main" thread >> - 4 addional libprocess worker threads >> - 1 background thread spawned by LevelDB >> - 1 backgrount thread spawned by libev >> >> Best regards, >> Benno >> >> On Mon, Sep 25, 2017 at 2:24 PM, James Vanns >> wrote: >> >> > Hi guys, >> > >> > Can anyone shed some light on the threading models/setup used by Mesos >> > and/or libprocess? I've got a problem with mixing/competing thread >> pools! I >> > introduced some OpenMP code and of course now I get N**2 threads started >> > each time a different libprocess thread executes my OMP code by way of a >> > mesos scheduler framework callback. Well, that's what I'm guessing! >> > >> > Anyway, I've come across LIBPROCESS_NUM_WORKER_THREADS and I can set >> that >> > to get a known #threads as workers - but my question is (this is now >> > curiosity more than anything) what are the remainder used for? Eg. If I >> > have a 4 core machine and indeed the above env var is set to 4 it >> appears >> > (without OMP) that libmesos or libprocess still spawn an additional 12 >> > threads. So what are those 12 threads used for? >> > >> > Oh - this is the (ancient) 0.28.3-2.0.1 release for Ubuntu 14.04 LTS, in >> > case that matters. >> > >> > Cheers, >> > >> > Jim >> > >> > -- >> > Senior Production Engineer >> > Industrial Light & Magic (ILM) >> > >> >> >> >> -- >> Benno Evers >> Software Engineer, Mesosphere >> > > > > -- > -- > Senior Code Pig > Industrial Light & Magic > -- -- Senior Code Pig Industrial Light & Magic
Re: RFC: Partition Awareness
> On Jun 21, 2017, at 10:16 AM, Megha Sharma wrote: > > Thank you all for the feedback. > To summarize, not killing tasks for non-Partition Aware frameworks will make > the schedulers see a higher volume of non terminal updates for tasks for > which they have already received a TASK_LOST but nothing new that they are > not seeing today. So, this shouldn’t be a breaking change for frameworks and > this will make the partition awareness logic simpler. I will update > MESOS-7215 with the details once the design is ready. What happens for short-lived frameworks? That is, the lost task comes back, causing the master to track its framework as disconnected, but the framework is gone and will never return. J
[GitHub] mesos pull request #238: Added Gitential and Lensa to powered-by
GitHub user kszucs opened a pull request: https://github.com/apache/mesos/pull/238 Added Gitential and Lensa to powered-by You can merge this pull request into a Git repository by running: $ git pull https://github.com/kszucs/mesos powered_by Alternatively you can review and apply these changes as the patch at: https://github.com/apache/mesos/pull/238.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #238 commit b455788fcc6173da281fae8af23cee0797f0d045 Author: Krisztián Szűcs Date: 2017-10-05T09:38:51Z Added Gitential and Lensa to powered-by ---
