Re: Add s390x support for Mesos CI

[Tomek Janiszewski]

I'm not sure if the mentioned matrix is the right one. For ARM we have
a different one. Maybe we need another one for the s390x?
See:
https://github.com/apache/mesos/blob/e79f6cb6ff82add9dfd7484d3f8f8253b76c0e91/docs/committing.md?plain=1#L31
https://lists.apache.org/thread/wd4jscv6kb4v3dgod390rj8jql1061mj

wt., 12 mar 2024 o 13:03 Yasir Ashfaq 
napisał(a):
>
> Hi Benjamin,
>
> Yes, I believe the configuration matrix needs to add an entry similar to :
>
> Configuration Matrix
> gcc
> s390x/ubuntu:18.04
> --verbose --disable-libtool-wrappers --disable-parallel-test-execution
> autotools
> ✅
> cmake
> ✅
>
> Configuration matrix must be living somewhere private to Mesos or in 
> Jenkins(using configuration matrix 
> plugin)
>  as I am unable to find configuration variables such as 
> “MESOS_TEST_AWAIT_TIMEOUT” environment being referred in Mesos source code.
>
> As mentioned here, 
> above configuration has also been tested as well.
>
> Please let me know if there is any way I can help to update configuration 
> matrix.
>
> Thanks & Regards,
> Yasir
>
> From: Benjamin Mahler 
> Date: Tuesday, 12 March 2024 at 4:43 AM
> To: dev@mesos.apache.org 
> Cc: Rishi Misra 
> Subject: [EXTERNAL] Re: Add s390x support for Mesos CI
> presumably you want to update the configuration matrix here?
>
> https://ci-builds.apache.org/job/Mesos/job/Mesos-Buildbot/
>
> not sure where this configuration lives though
>
> On Mon, Mar 11, 2024 at 1:28 AM Yasir Ashfaq 
> wrote:
>
> > Hi All,
> >
> > We recently added changes(https://github.com/apache/mesos/pull/449 ) to
> > provide s390x CI support for Mesos.
> > Even though the changes are merged, Mesos CI has not been enabled yet.
> >
> > As per https://issues.apache.org/jira/browse/INFRA-21433 , we have
> > provided apache four s390x nodes, hence, same nodes can be used to enable
> > Apache Mesos CI as well.
> >
> > Could you please let us know if there is anything further required from
> > our side to enable Mesos CI support for s390x.
> >
> > Thanks & Regards,
> > Yasir
> >

Re: Seeking contributions to fix Mesos website build

[Tomek Janiszewski]

It looks like job configuration has changed and it's using GitHub repo now
and could not find revision so build does not even start.

Now:
> Cloning repository https://gitbox.apache.org/repos/asf/mesos-site.git
> Avoid second fetch
 > git rev-parse origin/asf-site^{commit} # timeout=10
 > git rev-parse asf-site^{commit} # timeout=10
ERROR: Couldn't find any revision to build. Verify the repository and
branch configuration for this job.
Finished: FAILURE

Before:

> Cloning repository https://github.com/apache/mesos.git
> Avoid second fetch
 > git rev-parse origin/asf-site^{commit} # timeout=10
Checking out Revision f14e3b07149b7213aa3552c50ff059155b33effd
(origin/asf-site)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f14e3b07149b7213aa3552c50ff059155b33effd # timeout=10
Commit message: "Updated

czw., 23 cze 2022, 23:16 użytkownik Dave Lester 
napisał:

> Hi all,
>
> The build for the Mesos website is currently broken. It looks like several
> dependency updates via dependabot were merged into the codebase on May 22nd
> causing the issue along the way.
>
> The last successful website build
> https://ci-builds.apache.org/job/Mesos/job/Mesos-Websitebot/1268/ is
> based on the revision cd71826, which was committed May 4th.
>
> Can the two dependabot changes to “/site” be rolled back (9c7ccc2 and
> 9019e3a) or better yet is there a community member with Middleman / Ruby
> debugging experience that can help fix the build?
>
> Thanks,
> Dave
>

Re: Apache Mesos CI on ARM64

[Tomek Janiszewski]

Sure, we can give it a try.

pt., 9 lip 2021, 13:06 użytkownik Martin Tzvetanov Grigorov <
mgrigo...@apache.org> napisał:

> Hi,
>
> I am afraid we won't be able to allocate such powerful machine :-/
>
> The VM me and Charles Natali used for testing/debugging is 8 core @
> 2.4GHz, 16GB RAM and `make -j 4` takes 32 mins on it.
> `sudo make check` hangs at the moment, so I cannot tell how much time it
> takes.
>
> Do you think a similar VM could be useful for you ?
> For example for running the build and tests once per day.
>
> Regards,
> Martin
>
> On 2021/07/07 15:53:06, Tomek Janiszewski  wrote:
> > We used to have 96 cores and  32G of RAM but we used only 48 cores since
> > C++ builds are MEM heavy and our CI job took ~90minutes.
> >
> > śr., 7 lip 2021 o 08:45 Martin Tzvetanov Grigorov 
> > napisał(a):
> >
> > > Hi,
> > >
> > > On 2021/07/01 17:24:39, Charles-François Natali 
> > > wrote:
> > > > Can't we just use Martin's VM?
> > >
> > > What are the hardware specs for the VM you would prefer (CPUs, memory,
> > > disk, ...) ?
> > > Once I have these details I could request a VM for you.
> > >
> > > Another option is to use https://ci-builds.apache.org/computer/arm4/.
> It
> > > is a shared ARM64 VM for all Apache projects. You may need to contact
> > > Apache Infra team to see how to make use of it.
> > >
> > > Regards,
> > > Martin
> > >
> > > >
> > > > On Thu, 1 Jul 2021, 17:15 Tomek Janiszewski, 
> wrote:
> > > >
> > > > > It looks like we will not get a machine this month but I was
> pointed to
> > > > > https://www.oracle.com/cloud/free/#always-free it will be super
> slow
> > > but
> > > > > we can try.
> > > > >
> > > > > wt., 29 cze 2021 o 14:59 Tomek Janiszewski 
> > > napisał(a):
> > > > >
> > > > >> I can handle that. Let's wait for the machine, then we only need
> to
> > > > >> change the IP from the old arm machine to the new one and
> everything
> > > should
> > > > >> work as before.
> > > > >>
> > > > >> wt., 29 cze 2021 o 14:56 Qian Zhang 
> napisał(a):
> > > > >>
> > > > >>> I think currently Mesos CI only covers CentOS 7 and Ubuntu 16.04
> on
> > > > >>> x86_64:
> > > > >>> https://ci-builds.apache.org//job/Mesos/job/Mesos-Buildbot/. I
> am
> > > not
> > > > >>> sure
> > > > >>> how to add a new platform in it, maybe create a JIRA ticket for
> the
> > > ASF
> > > > >>> Infrastructure team? it seems we did it before:
> > > > >>> https://issues.apache.org/jira/browse/INFRA-15261.
> > > > >>>
> > > > >>>
> > > > >>> Regards,
> > > > >>> Qian Zhang
> > > > >>>
> > > > >>>
> > > > >>> On Tue, Jun 29, 2021 at 3:26 AM Tomek Janiszewski <
> jani...@gmail.com
> > > >
> > > > >>> wrote:
> > > > >>>
> > > > >>> > I created a request to Works On ARM
> > > > >>> > https://github.com/WorksOnArm/cluster/issues/278
> > > > >>> > If you are interested about history of Mesos on ARM
> > > > >>> > https://twitter.com/search?q=ARM%20%40janiszt
> > > > >>> >
> > > > >>> > pon., 28 cze 2021 o 19:40 Charles-François Natali <
> > > cf.nat...@gmail.com
> > > > >>> >
> > > > >>> > napisał(a):
> > > > >>> >
> > > > >>> > > Hey,
> > > > >>> > >
> > > > >>> > > I'm not sure who can arrange that - Qian maybe? - but yes
> having
> > > an
> > > > >>> ARM64
> > > > >>> > > CI would be great.
> > > > >>> > >
> > > > >>> > > Having access to Martin's VM really made it much simpler to
> > > debug the
> > > > >>> > > recent issue with libunwind.
> > > > >>> > >
> > > > >>> > > Generally having more CI hosts/pipelines would help, e.g. to
> > > build
> > > > >>> and
> > > > >>> > > test with ASAN and UBSAN.
> > > > >>> > >
> > > > >>> > >
> > > > >>> > >
> > > > >>> > > Charles
> > > > >>> > >
> > > > >>> > >
> > > > >>> > > On Mon, 28 Jun 2021, 16:20 Andreas Peters,
> > > 
> > > > >>> > wrote:
> > > > >>> > >
> > > > >>> > >> Hi!
> > > > >>> > >>
> > > > >>> > >> > Should we ask Mesos on ARM for new machine? Is anybody
> > > interested
> > > > >>> in
> > > > >>> > >> having
> > > > >>> > >> > ARM CI?
> > > > >>> > >>
> > > > >>> > >>
> > > > >>> > >> I think, if it does not take to much time for us then it
> would
> > > be a
> > > > >>> good
> > > > >>> > >> idea to build the packages for ARM again. :-)
> > > > >>> > >>
> > > > >>> > >> Best,
> > > > >>> > >> Andreas
> > > > >>> > >>
> > > > >>> > >>
> > > > >>> >
> > > > >>>
> > > > >>
> > > >
> > >
> >
>

Re: Apache Mesos CI on ARM64

[Tomek Janiszewski]

We used to have 96 cores and  32G of RAM but we used only 48 cores since
C++ builds are MEM heavy and our CI job took ~90minutes.

śr., 7 lip 2021 o 08:45 Martin Tzvetanov Grigorov 
napisał(a):

> Hi,
>
> On 2021/07/01 17:24:39, Charles-François Natali 
> wrote:
> > Can't we just use Martin's VM?
>
> What are the hardware specs for the VM you would prefer (CPUs, memory,
> disk, ...) ?
> Once I have these details I could request a VM for you.
>
> Another option is to use https://ci-builds.apache.org/computer/arm4/. It
> is a shared ARM64 VM for all Apache projects. You may need to contact
> Apache Infra team to see how to make use of it.
>
> Regards,
> Martin
>
> >
> > On Thu, 1 Jul 2021, 17:15 Tomek Janiszewski,  wrote:
> >
> > > It looks like we will not get a machine this month but I was pointed to
> > > https://www.oracle.com/cloud/free/#always-free it will be super slow
> but
> > > we can try.
> > >
> > > wt., 29 cze 2021 o 14:59 Tomek Janiszewski 
> napisał(a):
> > >
> > >> I can handle that. Let's wait for the machine, then we only need to
> > >> change the IP from the old arm machine to the new one and everything
> should
> > >> work as before.
> > >>
> > >> wt., 29 cze 2021 o 14:56 Qian Zhang  napisał(a):
> > >>
> > >>> I think currently Mesos CI only covers CentOS 7 and Ubuntu 16.04 on
> > >>> x86_64:
> > >>> https://ci-builds.apache.org//job/Mesos/job/Mesos-Buildbot/. I am
> not
> > >>> sure
> > >>> how to add a new platform in it, maybe create a JIRA ticket for the
> ASF
> > >>> Infrastructure team? it seems we did it before:
> > >>> https://issues.apache.org/jira/browse/INFRA-15261.
> > >>>
> > >>>
> > >>> Regards,
> > >>> Qian Zhang
> > >>>
> > >>>
> > >>> On Tue, Jun 29, 2021 at 3:26 AM Tomek Janiszewski  >
> > >>> wrote:
> > >>>
> > >>> > I created a request to Works On ARM
> > >>> > https://github.com/WorksOnArm/cluster/issues/278
> > >>> > If you are interested about history of Mesos on ARM
> > >>> > https://twitter.com/search?q=ARM%20%40janiszt
> > >>> >
> > >>> > pon., 28 cze 2021 o 19:40 Charles-François Natali <
> cf.nat...@gmail.com
> > >>> >
> > >>> > napisał(a):
> > >>> >
> > >>> > > Hey,
> > >>> > >
> > >>> > > I'm not sure who can arrange that - Qian maybe? - but yes having
> an
> > >>> ARM64
> > >>> > > CI would be great.
> > >>> > >
> > >>> > > Having access to Martin's VM really made it much simpler to
> debug the
> > >>> > > recent issue with libunwind.
> > >>> > >
> > >>> > > Generally having more CI hosts/pipelines would help, e.g. to
> build
> > >>> and
> > >>> > > test with ASAN and UBSAN.
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > > Charles
> > >>> > >
> > >>> > >
> > >>> > > On Mon, 28 Jun 2021, 16:20 Andreas Peters,
> 
> > >>> > wrote:
> > >>> > >
> > >>> > >> Hi!
> > >>> > >>
> > >>> > >> > Should we ask Mesos on ARM for new machine? Is anybody
> interested
> > >>> in
> > >>> > >> having
> > >>> > >> > ARM CI?
> > >>> > >>
> > >>> > >>
> > >>> > >> I think, if it does not take to much time for us then it would
> be a
> > >>> good
> > >>> > >> idea to build the packages for ARM again. :-)
> > >>> > >>
> > >>> > >> Best,
> > >>> > >> Andreas
> > >>> > >>
> > >>> > >>
> > >>> >
> > >>>
> > >>
> >
>

Re: Apache Mesos CI on ARM64

[Tomek Janiszewski]

It looks like we will not get a machine this month but I was pointed to
https://www.oracle.com/cloud/free/#always-free it will be super slow but we
can try.

wt., 29 cze 2021 o 14:59 Tomek Janiszewski  napisał(a):

> I can handle that. Let's wait for the machine, then we only need to change
> the IP from the old arm machine to the new one and everything should work
> as before.
>
> wt., 29 cze 2021 o 14:56 Qian Zhang  napisał(a):
>
>> I think currently Mesos CI only covers CentOS 7 and Ubuntu 16.04 on
>> x86_64:
>> https://ci-builds.apache.org//job/Mesos/job/Mesos-Buildbot/. I am not
>> sure
>> how to add a new platform in it, maybe create a JIRA ticket for the ASF
>> Infrastructure team? it seems we did it before:
>> https://issues.apache.org/jira/browse/INFRA-15261.
>>
>>
>> Regards,
>> Qian Zhang
>>
>>
>> On Tue, Jun 29, 2021 at 3:26 AM Tomek Janiszewski 
>> wrote:
>>
>> > I created a request to Works On ARM
>> > https://github.com/WorksOnArm/cluster/issues/278
>> > If you are interested about history of Mesos on ARM
>> > https://twitter.com/search?q=ARM%20%40janiszt
>> >
>> > pon., 28 cze 2021 o 19:40 Charles-François Natali 
>> > napisał(a):
>> >
>> > > Hey,
>> > >
>> > > I'm not sure who can arrange that - Qian maybe? - but yes having an
>> ARM64
>> > > CI would be great.
>> > >
>> > > Having access to Martin's VM really made it much simpler to debug the
>> > > recent issue with libunwind.
>> > >
>> > > Generally having more CI hosts/pipelines would help, e.g. to build and
>> > > test with ASAN and UBSAN.
>> > >
>> > >
>> > >
>> > > Charles
>> > >
>> > >
>> > > On Mon, 28 Jun 2021, 16:20 Andreas Peters, 
>> > wrote:
>> > >
>> > >> Hi!
>> > >>
>> > >> > Should we ask Mesos on ARM for new machine? Is anybody interested
>> in
>> > >> having
>> > >> > ARM CI?
>> > >>
>> > >>
>> > >> I think, if it does not take to much time for us then it would be a
>> good
>> > >> idea to build the packages for ARM again. :-)
>> > >>
>> > >> Best,
>> > >> Andreas
>> > >>
>> > >>
>> >
>>
>

Re: Apache Mesos CI on ARM64

[Tomek Janiszewski]

I can handle that. Let's wait for the machine, then we only need to change
the IP from the old arm machine to the new one and everything should work
as before.

wt., 29 cze 2021 o 14:56 Qian Zhang  napisał(a):

> I think currently Mesos CI only covers CentOS 7 and Ubuntu 16.04 on x86_64:
> https://ci-builds.apache.org//job/Mesos/job/Mesos-Buildbot/. I am not sure
> how to add a new platform in it, maybe create a JIRA ticket for the ASF
> Infrastructure team? it seems we did it before:
> https://issues.apache.org/jira/browse/INFRA-15261.
>
>
> Regards,
> Qian Zhang
>
>
> On Tue, Jun 29, 2021 at 3:26 AM Tomek Janiszewski 
> wrote:
>
> > I created a request to Works On ARM
> > https://github.com/WorksOnArm/cluster/issues/278
> > If you are interested about history of Mesos on ARM
> > https://twitter.com/search?q=ARM%20%40janiszt
> >
> > pon., 28 cze 2021 o 19:40 Charles-François Natali 
> > napisał(a):
> >
> > > Hey,
> > >
> > > I'm not sure who can arrange that - Qian maybe? - but yes having an
> ARM64
> > > CI would be great.
> > >
> > > Having access to Martin's VM really made it much simpler to debug the
> > > recent issue with libunwind.
> > >
> > > Generally having more CI hosts/pipelines would help, e.g. to build and
> > > test with ASAN and UBSAN.
> > >
> > >
> > >
> > > Charles
> > >
> > >
> > > On Mon, 28 Jun 2021, 16:20 Andreas Peters, 
> > wrote:
> > >
> > >> Hi!
> > >>
> > >> > Should we ask Mesos on ARM for new machine? Is anybody interested in
> > >> having
> > >> > ARM CI?
> > >>
> > >>
> > >> I think, if it does not take to much time for us then it would be a
> good
> > >> idea to build the packages for ARM again. :-)
> > >>
> > >> Best,
> > >> Andreas
> > >>
> > >>
> >
>

Re: Apache Mesos CI on ARM64

[Tomek Janiszewski]

I created a request to Works On ARM
https://github.com/WorksOnArm/cluster/issues/278
If you are interested about history of Mesos on ARM
https://twitter.com/search?q=ARM%20%40janiszt

pon., 28 cze 2021 o 19:40 Charles-François Natali 
napisał(a):

> Hey,
>
> I'm not sure who can arrange that - Qian maybe? - but yes having an ARM64
> CI would be great.
>
> Having access to Martin's VM really made it much simpler to debug the
> recent issue with libunwind.
>
> Generally having more CI hosts/pipelines would help, e.g. to build and
> test with ASAN and UBSAN.
>
>
>
> Charles
>
>
> On Mon, 28 Jun 2021, 16:20 Andreas Peters,  wrote:
>
>> Hi!
>>
>> > Should we ask Mesos on ARM for new machine? Is anybody interested in
>> having
>> > ARM CI?
>>
>>
>> I think, if it does not take to much time for us then it would be a good
>> idea to build the packages for ARM again. :-)
>>
>> Best,
>> Andreas
>>
>>

Re: Apache Mesos CI on ARM64

[Tomek Janiszewski]

Hi

Unfortunately after the havoc around Mesos future Packet decided to take
back ARM CI instance.
AFAIk PPC64LE is a runner that calls another job that runs on ARM but now
there is no ARM machine for this project so it fails :(
https://ci-builds.apache.org/job/Mesos/job/Mesos-Buildbot-ARM/

Should we ask Mesos on ARM for new machine? Is anybody interested in having
ARM CI?
I have an ansible playbook to set ARM machine for Ci
https://github.com/janisz/mesos-on-arm-playbook/blob/master/jenkins.yml

Hello,
>
>
>
> I wanted to inform you that given the recent news of Apache Foundation
> sunsetting the Mesos project, we would like to proceed and remove / take
> back the original server (1 ThunderX) reserved under WoA infra. And this
> project is no longer in list of migration to new Altras.
>
>
>
> Regards
>
> Manisha
>

pon., 28 cze 2021 o 13:57 Martin Tzvetanov Grigorov 
napisał(a):

> Hello Mesos devs,
>
> Recently I've reported an issue with running Mesos on Linux ARM64 [1]
> Many thanks to Charles Natali for fixing the issue!
>
> At [2] I have asked whether anyone is familiar with this Jenkins job [3].
> Its name says "ARM" but in its logs I see:
>
> "20:51:43 Building remotely on ubuntu-ppc64le (ppc64le) in workspace
> /home/jenkins/jenkins-slave/workspace/Mesos/Mesos-Buildbot-ARM" [4]. That
> is, it actually builds on PPC64LE!
>
> Questions:
>
> I) Is there another CI job that actually builds on ARM64/AARCH64 ?
>
> II) If there no such job at the moment then is the Mesos PMC interested to
> have one ?
> I could organize a donation of a VM that could be used as Jenkins Agent.
>
>
> Kind regards,
> Martin
>
> 1. https://issues.apache.org/jira/browse/MESOS-10223
> 2.
> https://issues.apache.org/jira/browse/MESOS-10223?focusedCommentId=17360874&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17360874
> 3. https://builds.apache.org/job/Mesos/job/Mesos-Buildbot-ARM/
> 4. https://builds.apache.org/job/Mesos/job/Mesos-Buildbot-ARM/41/console
>

Re: [BULK]Re: [BULK]Call for active contributors

[Tomek Janiszewski]

I'm in
I can help with ARM CI, UI and some C++

czw., 4 mar 2021 o 16:04 Thomas Langé  napisał(a):

> Same for me, I'm available to share my knowledge and actively contribute
> to Mesos project.
>
> Thomas
> --
> *From:* Haijiang Chen 
> *Sent:* Thursday, 4 March 2021 16:01
> *To:* u...@mesos.apache.org 
> *Cc:* mesos 
> *Subject:* [BULK]Re: [BULK]Call for active contributors
>
> I am willing to contribute to Mesos on windows based on my current
> experiences.
>
> - Haijiang
>
> On Thu, Mar 4, 2021 at 10:56 PM Grégoire Seux  wrote:
>
> Already answered to the other thread. I'm in.
>
> -- ​
> Grégoire
> --
> *From:* Qian Zhang 
> *Sent:* Thursday, March 4, 2021 3:38 PM
> *To:* mesos ; user 
> *Subject:* [BULK]Call for active contributors
>
> Hi folks,
>
> Please reply to this mail if you plan to actively contribute to Mesos and
> want to become a committer and PMC member in future.
>
>
> Regards,
> Qian Zhang
>
>

Re: Next Steps

[Tomek Janiszewski]

I think we can elect new committers. Currently we have 49 but most of them
have left the project long ago.
https://projects.apache.org/committee.html?mesos

czw., 18 lut 2021 o 18:18 Charles-François Natali 
napisał(a):

> Speaking as someone who contributed a few patches and would like to get
> more involved, I find it a bit difficult to get MRs reviewed and merged.
> I think it's probably because the current committers have other priorities
> now that D2iQ focus has shifted, which is understandable but makes it
> harder for outsiders to contribute.
> Is there anything which could be done about that?
>
> Cheers,
>
>
>
> On Thu, 18 Feb 2021, 14:30 Qian Zhang,  wrote:
>
>> Hi Vinod,
>>
>> I am still interested in the project. As other folks said, we need to
>> have a direction for the project. I think there are still a lot of Mesos
>> users/customers in the mail list, can you please send another mail to
>> collect their requirements / pain points on Mesos, and then we can try to
>> set up a roadmap for the project to move forward.
>>
>>
>> Regards,
>> Qian Zhang
>>
>>
>> On Thu, Feb 18, 2021 at 9:16 PM Andrei Sekretenko 
>> wrote:
>>
>>> IIUC, Attic is not intended for projects which still have active users
>>> and thus might be in need of fixing bugs.
>>>
>>> Key items about moving project to Attic:
>>> > It is not intended to:
>>> > - Rebuild community
>>> > - Make bugfixes
>>> > - Make releases
>>>
>>> >Projects whose PMC are unable to muster 3 votes for a release, who have
>>> no active committers or are unable to fulfill their reporting duties to the
>>> board are all good candidates for the Attic.
>>>
>>> As a D2iQ employee, I can say that if we find a bug critical for our
>>> customers, we will be interested in fixing that. Should the project be
>>> moved into Attic, the fix will be present only in forks (which might
>>> mean our internal forks).
>>>
>>> I could imagine that other entities and people using Mesos are in a
>>> similar position with regards to bugfixes.
>>> If this is true, then moving the project to Attic in the near future
>>> is not a proper solution to the issue of insufficient bandwidth of the
>>> active PMC members/chair.
>>>
>>> ---
>>> A long-term future of the project is a different story, which, in my
>>> personal view, will "end" either in moving the project into Attic or
>>> in shifting the project direction from what it used to be in the
>>> recent few years to something substantially different. IMO, this
>>> requires a  _separate_ discussion.
>>>
>>> Damien's questions sound like a good starting point for that
>>> discussion, I'll try to answer them from my committer/PMC member
>>> perspective when I have enough time.
>>>
>>> On Thu, 18 Feb 2021 at 12:49, Charles-François Natali
>>>  wrote:
>>> >
>>> > Thanks Tomek, that's what I suspected.
>>> > It would therefore make it much more difficult for anyone to carry on
>>> since it would effectively have to be a fork, etc.
>>> > I think it'd be a bit of a shame, but I understand Benjamin's point.
>>> > I hope it can be avoided.
>>> >
>>> >
>>> > Cheers,
>>> >
>>> >
>>> >
>>> > On Thu, 18 Feb 2021, 11:02 Tomek Janiszewski, 
>>> wrote:
>>> >>
>>> >> Moving to attic is making project read only
>>> >> https://attic.apache.org/
>>> >> https://attic.apache.org/projects/aurora.html
>>> >>
>>> >> czw., 18 lut 2021, 11:56 użytkownik Charles-François Natali <
>>> cf.nat...@gmail.com> napisał:
>>> >>>
>>> >>> I'm not familiar with the attic but would it still allow to actually
>>> >>> develop, make commits to the repository etc?
>>> >>>
>>> >>>
>>> >>> On Thu, 18 Feb 2021, 08:27 Benjamin Bannier, 
>>> wrote:
>>> >>>
>>> >>> > Hi Vinod,
>>> >>> >
>>> >>> > > I would like to start a discussion around the future of the Mesos
>>> >>> > project.
>>> >>> > >
>>> >>> > > As you are probably aware, the number of active committers and
>>> >>> > contributors
>>> >>

Re: Next Steps

[Tomek Janiszewski]

Moving to attic is making project read only
https://attic.apache.org/
https://attic.apache.org/projects/aurora.html

czw., 18 lut 2021, 11:56 użytkownik Charles-François Natali <
cf.nat...@gmail.com> napisał:

> I'm not familiar with the attic but would it still allow to actually
> develop, make commits to the repository etc?
>
>
> On Thu, 18 Feb 2021, 08:27 Benjamin Bannier,  wrote:
>
> > Hi Vinod,
> >
> > > I would like to start a discussion around the future of the Mesos
> > project.
> > >
> > > As you are probably aware, the number of active committers and
> > contributors
> > > to the project have declined significantly over time. As of today,
> > there's
> > > no active development of any features or a public release planned. On
> the
> > > flip side, I do know there are a few companies who are still actively
> > using
> > > Mesos.
> >
> > Thanks for starting this discussion Vinod. Looking at Slack, mailing
> > lists, JIRA and reviewboard/github the project has wound down a lot in
> > the last 12+ months.
> >
> > > Given that, we need to assess if there's interest in the community to
> > keep
> > > this project moving forward. Specifically, we need some active
> committers
> > > and PMC members who are going to manage the project. Ideally, these
> would
> > > be people who are using Mesos in some capacity and can make code
> > > contributions.
> >
> > While I have seen a few non-committer folks contribute patches in the
> > last months, I feel it might be too late to bootstrap an active
> > community at this point.
> >
> > Apache Mesos is still mentioned prominently in the docs of a number of
> > other projects which gives off the impression of an active and
> > maintained project. In reality almost nobody is working on issues or
> > available to help users, and basing a new project on Apache Mesos these
> > days is probably not a good idea. I honestly do not see that to change
> > should new people step up and IMO the most honest way forward would be
> > to move the project to the attic to clearly communicate that the project
> > has moved into another phase; this wouldn't preclude folks from using or
> > further developing Apache Mesos, but would give a clear signal to users.
> >
> > > If there is no active interest, we will likely need to figure out steps
> > for
> > > retiring the project.
> > >
> > > *Call for action: If you are interested in becoming a committer/PMC
> > member
> > > (including PMC chair) and actively maintain the project, please reply
> to
> > > this email.*
> >
> > Like I wrote above, I would be in favor of a vote to move Apache Mesos
> > to the attic.
> >
> >
> > Cheers,
> >
> > Benjamin
> >
>

[GSoC] Google Summer of Code

[Tomek Janiszewski]

Hi

It looks like Apache Foundation was selected to Google Summer of Code
https://summerofcode.withgoogle.com/organizations/5718432427802624/
Do we plan to submit any project related to Mesos. I was thinking about a
project to refresh Mesos UI (catch up with features, upgrade to latest
Angular (or rethink the framework)).
What do you think?

Best
Tomek

Re: Introducing `support/mesos-build.sh`

[Tomek Janiszewski]

Other jobs finish in 50 min but they do clang/gcc and cmake/auttools checks
so total build time takes 2h.
I hope we can make next release with ARM binaries. Tere was some proposal
of making official Mesos binaries (debs, rpms etc) so we can plug in this
process.

wt., 20 mar 2018 o 15:35 użytkownik Ed Vielmetti  napisał:

> Congratulations Tomek and good job.
>
> How does build time on this system compare to other systems?
>
> When you have something packaged for release I'd love to give it a try.
>
> On Tue, Mar 20, 2018 at 8:54 AM, Tomek Janiszewski 
> wrote:
>
>> Thank you!
>>
>> ARM builds are passing right now [0]. We are using ubuntu-16.04-arm image
>> [1]. I think from next release we can consider ARM as a supported platform!
>>
>> 0:
>> https://builds.apache.org/job/Mesos-Buildbot-ARM/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-java%20--disable-python,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1%20%20MESOS_TEST_AWAIT_TIMEOUT=60secs%20JOBS=16,label_exp=arm/453/
>> 1: https://hub.docker.com/r/mesos/mesos-build/tags/
>>
>> wt., 20 mar 2018 o 13:30 użytkownik Benjamin Bannier <
>> benjamin.bann...@mesosphere.io> napisał:
>>
>>> Done.
>>>
>>> > On Mar 20, 2018, at 10:46 AM, Tomek Janiszewski 
>>> wrote:
>>> >
>>> > Thanks for merging. Can we push this image to dockerhub tagged as
>>> > ubuntu-16.04-arm? Then we will need to update CI configuration to:
>>> > JOBS=16 OS=ubuntu-16.04-arm BUILDTOOL=cmake COMPILER=gcc
>>> > CONFIGURATION='--disable-java --disable-python
>>> --disable-libtool-wrappers'
>>> > ENVIRONMENT='GLOG_v=1 MESOS_VERBOSE=1' ../mesos-build.sh
>>> > or
>>> > JOBS=16 OS=ubuntu-16.04-arm BUILDTOOL=autotools COMPILER=gcc
>>> > CONFIGURATION='--disable-java --disable-python
>>> --disable-libtool-wrappers'
>>> > ENVIRONMENT='GLOG_v=1 MESOS_VERBOSE=1' ./support/mesos-build.sh
>>> >
>>> >
>>> > pon., 19 mar 2018 o 16:24 użytkownik Tomek Janiszewski <
>>> jani...@gmail.com>
>>> > napisał:
>>> >
>>> >> Dockerfile for ARM with CMake support
>>> https://reviews.apache.org/r/66138/
>>> >>
>>> >> pon., 12 lut 2018 o 15:41 użytkownik Tomek Janiszewski <
>>> jani...@gmail.com>
>>> >> napisał:
>>> >>
>>> >>> How can I use it for our ARM CI?
>>> >>>
>>> >>> JOBS=16 OS=arm64v8/ubuntu:16.04  ./support/mesos-build.sh
>>> >>> + set -e
>>> >>> + set -o pipefail
>>> >>> + : arm64v8/ubuntu:16.04
>>> >>> + : autotools
>>> >>> + : gcc
>>> >>> + : '--verbose --disable-libtool-wrappers'
>>> >>> + : 'GLOG_v=1 MESOS_VERBOSE=1'
>>> >>> + : 16
>>> >>> ++ git rev-parse --show-toplevel
>>> >>> + MESOS_DIR=/home/janisz/mesos
>>> >>> ++ git diff-index --quiet HEAD --
>>> >>> + docker run --rm -v /home/janisz/mesos:/SRC:Z -e
>>> BUILDTOOL=autotools -e
>>> >>> COMPILER=gcc -e 'CONFIGURATION=--verbose --disable-libtool-wrappers'
>>> -e
>>> >>> 'ENVIRONMENT=GLOG_v=1 MESOS_VERBOSE=1' -e JOBS=16
>>> >>> mesos/mesos-build:arm64v8/ubuntu-16.04
>>> >>> docker: invalid reference format.
>>> >>> See 'docker run --help'.
>>> >>>
>>> >>>
>>> >>> czw., 8 lut 2018 o 07:38 użytkownik Michael Park 
>>> >>> napisał:
>>> >>>
>>> >>>> The first run looks good!
>>> >>>> https://builds.apache.org/job/Mesos-Buildbot/4890/
>>> >>>>
>>> >>>> [image: Screen Shot 2018-02-07 at 10.30.51 PM.png]
>>> >>>> On Wed, Feb 7, 2018 at 8:39 PM Michael Park 
>>> wrote:
>>> >>>>
>>> >>>>> Yep, Just landed! Waiting for
>>> >>>> https://builds.apache.org/job/Mesos-Buildbot to
>>> >>>>> pick it up.
>>> >>>>>
>>> >>>>> On Wed, Feb 7, 2018 at 8:27 PM Vinod Kone 
>>> >>>> wrote:
>>> >>>>>
>>> >>>>>> Yay, thanks MPark! Has the change landed already?
>>> >>>>>>
>>> >>>>>> On Wed, Feb 7, 2018 at 8:23 PM, Michael Park 
>>> >>>> wrote:
>>> >>>>>>
>>> >>>>>>> Many of you probably know that we currently have
>>> >>>>>> `support/docker-build.sh`
>>> >>>>>>> to power our CI for our various configurations. One of the
>>> problems
>>> >>>> for
>>> >>>>>> us
>>> >>>>>>> has been that we create a `Dockerfile` ad-hoc and invoke `docker
>>> >>>> build`
>>> >>>>>>> with it. This is very inefficient and also leads to flaky issues
>>> >>>> around
>>> >>>>>>> `apt-get install`.
>>> >>>>>>>
>>> >>>>>>> I've introduced `support/mesos-build.sh` which operates off of
>>> >>>> docker
>>> >>>>>>> images hosted on Dockerhub instead, and should aid in bringing us
>>> >>>> faster
>>> >>>>>>> and more stable CI results!
>>> >>>>>>>
>>> >>>>>>> As a bonus, we now also test Clang on the CentOS 7!
>>> >>>>>>>
>>> >>>>>>> Thanks,
>>> >>>>>>>
>>> >>>>>>> MPark
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>>
>>>
>>>
>
>
> --
> Edward Vielmetti
> +1 734 330 2465 <(734)%20330-2465>
> e...@packet.net
> http://worksonarm.com
>

Re: Introducing `support/mesos-build.sh`

[Tomek Janiszewski]

Thank you!

ARM builds are passing right now [0]. We are using ubuntu-16.04-arm image
[1]. I think from next release we can consider ARM as a supported platform!

0:
https://builds.apache.org/job/Mesos-Buildbot-ARM/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-java%20--disable-python,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1%20%20MESOS_TEST_AWAIT_TIMEOUT=60secs%20JOBS=16,label_exp=arm/453/
1: https://hub.docker.com/r/mesos/mesos-build/tags/

wt., 20 mar 2018 o 13:30 użytkownik Benjamin Bannier <
benjamin.bann...@mesosphere.io> napisał:

> Done.
>
> > On Mar 20, 2018, at 10:46 AM, Tomek Janiszewski 
> wrote:
> >
> > Thanks for merging. Can we push this image to dockerhub tagged as
> > ubuntu-16.04-arm? Then we will need to update CI configuration to:
> > JOBS=16 OS=ubuntu-16.04-arm BUILDTOOL=cmake COMPILER=gcc
> > CONFIGURATION='--disable-java --disable-python
> --disable-libtool-wrappers'
> > ENVIRONMENT='GLOG_v=1 MESOS_VERBOSE=1' ../mesos-build.sh
> > or
> > JOBS=16 OS=ubuntu-16.04-arm BUILDTOOL=autotools COMPILER=gcc
> > CONFIGURATION='--disable-java --disable-python
> --disable-libtool-wrappers'
> > ENVIRONMENT='GLOG_v=1 MESOS_VERBOSE=1' ./support/mesos-build.sh
> >
> >
> > pon., 19 mar 2018 o 16:24 użytkownik Tomek Janiszewski <
> jani...@gmail.com>
> > napisał:
> >
> >> Dockerfile for ARM with CMake support
> https://reviews.apache.org/r/66138/
> >>
> >> pon., 12 lut 2018 o 15:41 użytkownik Tomek Janiszewski <
> jani...@gmail.com>
> >> napisał:
> >>
> >>> How can I use it for our ARM CI?
> >>>
> >>> JOBS=16 OS=arm64v8/ubuntu:16.04  ./support/mesos-build.sh
> >>> + set -e
> >>> + set -o pipefail
> >>> + : arm64v8/ubuntu:16.04
> >>> + : autotools
> >>> + : gcc
> >>> + : '--verbose --disable-libtool-wrappers'
> >>> + : 'GLOG_v=1 MESOS_VERBOSE=1'
> >>> + : 16
> >>> ++ git rev-parse --show-toplevel
> >>> + MESOS_DIR=/home/janisz/mesos
> >>> ++ git diff-index --quiet HEAD --
> >>> + docker run --rm -v /home/janisz/mesos:/SRC:Z -e BUILDTOOL=autotools
> -e
> >>> COMPILER=gcc -e 'CONFIGURATION=--verbose --disable-libtool-wrappers' -e
> >>> 'ENVIRONMENT=GLOG_v=1 MESOS_VERBOSE=1' -e JOBS=16
> >>> mesos/mesos-build:arm64v8/ubuntu-16.04
> >>> docker: invalid reference format.
> >>> See 'docker run --help'.
> >>>
> >>>
> >>> czw., 8 lut 2018 o 07:38 użytkownik Michael Park 
> >>> napisał:
> >>>
> >>>> The first run looks good!
> >>>> https://builds.apache.org/job/Mesos-Buildbot/4890/
> >>>>
> >>>> [image: Screen Shot 2018-02-07 at 10.30.51 PM.png]
> >>>> On Wed, Feb 7, 2018 at 8:39 PM Michael Park  wrote:
> >>>>
> >>>>> Yep, Just landed! Waiting for
> >>>> https://builds.apache.org/job/Mesos-Buildbot to
> >>>>> pick it up.
> >>>>>
> >>>>> On Wed, Feb 7, 2018 at 8:27 PM Vinod Kone 
> >>>> wrote:
> >>>>>
> >>>>>> Yay, thanks MPark! Has the change landed already?
> >>>>>>
> >>>>>> On Wed, Feb 7, 2018 at 8:23 PM, Michael Park 
> >>>> wrote:
> >>>>>>
> >>>>>>> Many of you probably know that we currently have
> >>>>>> `support/docker-build.sh`
> >>>>>>> to power our CI for our various configurations. One of the problems
> >>>> for
> >>>>>> us
> >>>>>>> has been that we create a `Dockerfile` ad-hoc and invoke `docker
> >>>> build`
> >>>>>>> with it. This is very inefficient and also leads to flaky issues
> >>>> around
> >>>>>>> `apt-get install`.
> >>>>>>>
> >>>>>>> I've introduced `support/mesos-build.sh` which operates off of
> >>>> docker
> >>>>>>> images hosted on Dockerhub instead, and should aid in bringing us
> >>>> faster
> >>>>>>> and more stable CI results!
> >>>>>>>
> >>>>>>> As a bonus, we now also test Clang on the CentOS 7!
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> MPark
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
>
>

Re: Introducing `support/mesos-build.sh`

[Tomek Janiszewski]

Thanks for merging. Can we push this image to dockerhub tagged as
ubuntu-16.04-arm? Then we will need to update CI configuration to:
JOBS=16 OS=ubuntu-16.04-arm BUILDTOOL=cmake COMPILER=gcc
CONFIGURATION='--disable-java --disable-python --disable-libtool-wrappers'
ENVIRONMENT='GLOG_v=1 MESOS_VERBOSE=1' ../mesos-build.sh
or
JOBS=16 OS=ubuntu-16.04-arm BUILDTOOL=autotools COMPILER=gcc
CONFIGURATION='--disable-java --disable-python --disable-libtool-wrappers'
ENVIRONMENT='GLOG_v=1 MESOS_VERBOSE=1' ./support/mesos-build.sh


pon., 19 mar 2018 o 16:24 użytkownik Tomek Janiszewski 
napisał:

> Dockerfile for ARM with CMake support https://reviews.apache.org/r/66138/
>
> pon., 12 lut 2018 o 15:41 użytkownik Tomek Janiszewski 
> napisał:
>
>> How can I use it for our ARM CI?
>>
>> JOBS=16 OS=arm64v8/ubuntu:16.04  ./support/mesos-build.sh
>> + set -e
>> + set -o pipefail
>> + : arm64v8/ubuntu:16.04
>> + : autotools
>> + : gcc
>> + : '--verbose --disable-libtool-wrappers'
>> + : 'GLOG_v=1 MESOS_VERBOSE=1'
>> + : 16
>> ++ git rev-parse --show-toplevel
>> + MESOS_DIR=/home/janisz/mesos
>> ++ git diff-index --quiet HEAD --
>> + docker run --rm -v /home/janisz/mesos:/SRC:Z -e BUILDTOOL=autotools -e
>> COMPILER=gcc -e 'CONFIGURATION=--verbose --disable-libtool-wrappers' -e
>> 'ENVIRONMENT=GLOG_v=1 MESOS_VERBOSE=1' -e JOBS=16
>> mesos/mesos-build:arm64v8/ubuntu-16.04
>> docker: invalid reference format.
>> See 'docker run --help'.
>>
>>
>> czw., 8 lut 2018 o 07:38 użytkownik Michael Park 
>> napisał:
>>
>>> The first run looks good!
>>> https://builds.apache.org/job/Mesos-Buildbot/4890/
>>>
>>> [image: Screen Shot 2018-02-07 at 10.30.51 PM.png]
>>> On Wed, Feb 7, 2018 at 8:39 PM Michael Park  wrote:
>>>
>>> > Yep, Just landed! Waiting for
>>> https://builds.apache.org/job/Mesos-Buildbot to
>>> > pick it up.
>>> >
>>> > On Wed, Feb 7, 2018 at 8:27 PM Vinod Kone 
>>> wrote:
>>> >
>>> >> Yay, thanks MPark! Has the change landed already?
>>> >>
>>> >> On Wed, Feb 7, 2018 at 8:23 PM, Michael Park 
>>> wrote:
>>> >>
>>> >> > Many of you probably know that we currently have
>>> >> `support/docker-build.sh`
>>> >> > to power our CI for our various configurations. One of the problems
>>> for
>>> >> us
>>> >> > has been that we create a `Dockerfile` ad-hoc and invoke `docker
>>> build`
>>> >> > with it. This is very inefficient and also leads to flaky issues
>>> around
>>> >> > `apt-get install`.
>>> >> >
>>> >> > I've introduced `support/mesos-build.sh` which operates off of
>>> docker
>>> >> > images hosted on Dockerhub instead, and should aid in bringing us
>>> faster
>>> >> > and more stable CI results!
>>> >> >
>>> >> > As a bonus, we now also test Clang on the CentOS 7!
>>> >> >
>>> >> > Thanks,
>>> >> >
>>> >> > MPark
>>> >> >
>>> >>
>>> >
>>>
>>

Re: Introducing `support/mesos-build.sh`

[Tomek Janiszewski]

Dockerfile for ARM with CMake support https://reviews.apache.org/r/66138/

pon., 12 lut 2018 o 15:41 użytkownik Tomek Janiszewski 
napisał:

> How can I use it for our ARM CI?
>
> JOBS=16 OS=arm64v8/ubuntu:16.04  ./support/mesos-build.sh
> + set -e
> + set -o pipefail
> + : arm64v8/ubuntu:16.04
> + : autotools
> + : gcc
> + : '--verbose --disable-libtool-wrappers'
> + : 'GLOG_v=1 MESOS_VERBOSE=1'
> + : 16
> ++ git rev-parse --show-toplevel
> + MESOS_DIR=/home/janisz/mesos
> ++ git diff-index --quiet HEAD --
> + docker run --rm -v /home/janisz/mesos:/SRC:Z -e BUILDTOOL=autotools -e
> COMPILER=gcc -e 'CONFIGURATION=--verbose --disable-libtool-wrappers' -e
> 'ENVIRONMENT=GLOG_v=1 MESOS_VERBOSE=1' -e JOBS=16
> mesos/mesos-build:arm64v8/ubuntu-16.04
> docker: invalid reference format.
> See 'docker run --help'.
>
>
> czw., 8 lut 2018 o 07:38 użytkownik Michael Park 
> napisał:
>
>> The first run looks good!
>> https://builds.apache.org/job/Mesos-Buildbot/4890/
>>
>> [image: Screen Shot 2018-02-07 at 10.30.51 PM.png]
>> On Wed, Feb 7, 2018 at 8:39 PM Michael Park  wrote:
>>
>> > Yep, Just landed! Waiting for
>> https://builds.apache.org/job/Mesos-Buildbot to
>> > pick it up.
>> >
>> > On Wed, Feb 7, 2018 at 8:27 PM Vinod Kone  wrote:
>> >
>> >> Yay, thanks MPark! Has the change landed already?
>> >>
>> >> On Wed, Feb 7, 2018 at 8:23 PM, Michael Park  wrote:
>> >>
>> >> > Many of you probably know that we currently have
>> >> `support/docker-build.sh`
>> >> > to power our CI for our various configurations. One of the problems
>> for
>> >> us
>> >> > has been that we create a `Dockerfile` ad-hoc and invoke `docker
>> build`
>> >> > with it. This is very inefficient and also leads to flaky issues
>> around
>> >> > `apt-get install`.
>> >> >
>> >> > I've introduced `support/mesos-build.sh` which operates off of docker
>> >> > images hosted on Dockerhub instead, and should aid in bringing us
>> faster
>> >> > and more stable CI results!
>> >> >
>> >> > As a bonus, we now also test Clang on the CentOS 7!
>> >> >
>> >> > Thanks,
>> >> >
>> >> > MPark
>> >> >
>> >>
>> >
>>
>

Re: [MoA] Update Jenkins ARM configuration

[Tomek Janiszewski]

Thank you James! Jenkins build is back to normal : Mesos-Buildbot-ARM

-- Forwarded message -
From: Apache Jenkins Server 
Date: sob., 17.03.2018, 02:16
Subject: Jenkins build is back to normal : Mesos-Buildbot-ARM »
autotools,gcc,--verbose --disable-libtool-wrappers --disable-java
--disable-python,GLOG_v=1 MESOS_VERBOSE=1
MESOS_TEST_AWAIT_TIMEOUT=60secs,arm #442
To: 


See <
https://builds.apache.org/job/Mesos-Buildbot-ARM/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-java%20--disable-python,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1%20%20MESOS_TEST_AWAIT_TIMEOUT=60secs,label_exp=arm/442/display/redirect?page=changes
>


pt., 16.03.2018, 19:17 użytkownik Tomek Janiszewski 
napisał:

> Thanks, I hope this fix ARM builds
>
> pt., 16.03.2018, 18:35 użytkownik James Peach  napisał:
>
>>
>>
>> > On Mar 16, 2018, at 8:27 AM, James Peach  wrote:
>> >
>> >
>> >
>> >> On Mar 16, 2018, at 5:11 AM, Tomek Janiszewski 
>> wrote:
>> >>
>> >> Hey
>> >>
>> >> Who can edit Jenkins configuration? I noticed we run tests with the
>> wrong
>> >> configuration (we miss --disable-libtool-wrappers') it should
>> >> be CONFIGURATION='--disable-java --disable-python
>> >> --disable-libtool-wrappers'
>> >> Can you fix it, please?
>> >>
>> >> https://issues.apache.org/jira/browse/MESOS-7500
>> >
>> > Thanks Tomek, I will take care of that today!
>>
>> done
>>
>

Re: [MoA] Update Jenkins ARM configuration

[Tomek Janiszewski]

Thanks, I hope this fix ARM builds

pt., 16.03.2018, 18:35 użytkownik James Peach  napisał:

>
>
> > On Mar 16, 2018, at 8:27 AM, James Peach  wrote:
> >
> >
> >
> >> On Mar 16, 2018, at 5:11 AM, Tomek Janiszewski 
> wrote:
> >>
> >> Hey
> >>
> >> Who can edit Jenkins configuration? I noticed we run tests with the
> wrong
> >> configuration (we miss --disable-libtool-wrappers') it should
> >> be CONFIGURATION='--disable-java --disable-python
> >> --disable-libtool-wrappers'
> >> Can you fix it, please?
> >>
> >> https://issues.apache.org/jira/browse/MESOS-7500
> >
> > Thanks Tomek, I will take care of that today!
>
> done
>

[MoA] Update Jenkins ARM configuration

[Tomek Janiszewski]

Hey

Who can edit Jenkins configuration? I noticed we run tests with the wrong
configuration (we miss --disable-libtool-wrappers') it should
be CONFIGURATION='--disable-java --disable-python
--disable-libtool-wrappers'
Can you fix it, please?

https://issues.apache.org/jira/browse/MESOS-7500

Thanks
Tomek

Re: Introducing `support/mesos-build.sh`

[Tomek Janiszewski]

How can I use it for our ARM CI?

JOBS=16 OS=arm64v8/ubuntu:16.04  ./support/mesos-build.sh
+ set -e
+ set -o pipefail
+ : arm64v8/ubuntu:16.04
+ : autotools
+ : gcc
+ : '--verbose --disable-libtool-wrappers'
+ : 'GLOG_v=1 MESOS_VERBOSE=1'
+ : 16
++ git rev-parse --show-toplevel
+ MESOS_DIR=/home/janisz/mesos
++ git diff-index --quiet HEAD --
+ docker run --rm -v /home/janisz/mesos:/SRC:Z -e BUILDTOOL=autotools -e
COMPILER=gcc -e 'CONFIGURATION=--verbose --disable-libtool-wrappers' -e
'ENVIRONMENT=GLOG_v=1 MESOS_VERBOSE=1' -e JOBS=16
mesos/mesos-build:arm64v8/ubuntu-16.04
docker: invalid reference format.
See 'docker run --help'.


czw., 8 lut 2018 o 07:38 użytkownik Michael Park  napisał:

> The first run looks good!
> https://builds.apache.org/job/Mesos-Buildbot/4890/
>
> [image: Screen Shot 2018-02-07 at 10.30.51 PM.png]
> On Wed, Feb 7, 2018 at 8:39 PM Michael Park  wrote:
>
> > Yep, Just landed! Waiting for
> https://builds.apache.org/job/Mesos-Buildbot to
> > pick it up.
> >
> > On Wed, Feb 7, 2018 at 8:27 PM Vinod Kone  wrote:
> >
> >> Yay, thanks MPark! Has the change landed already?
> >>
> >> On Wed, Feb 7, 2018 at 8:23 PM, Michael Park  wrote:
> >>
> >> > Many of you probably know that we currently have
> >> `support/docker-build.sh`
> >> > to power our CI for our various configurations. One of the problems
> for
> >> us
> >> > has been that we create a `Dockerfile` ad-hoc and invoke `docker
> build`
> >> > with it. This is very inefficient and also leads to flaky issues
> around
> >> > `apt-get install`.
> >> >
> >> > I've introduced `support/mesos-build.sh` which operates off of docker
> >> > images hosted on Dockerhub instead, and should aid in bringing us
> faster
> >> > and more stable CI results!
> >> >
> >> > As a bonus, we now also test Clang on the CentOS 7!
> >> >
> >> > Thanks,
> >> >
> >> > MPark
> >> >
> >>
> >
>

Looking for shepherd

[Tomek Janiszewski]

I need someone to review and merge this change
https://reviews.apache.org/r/65569/
It should fix ARM tests.

Re: Build failed in Jenkins: Mesos-Buildbot » autotools,clang,--verbose --disable-libtool-wrappers,GLOG_v=1 MESOS_VERBOSE=1,ubuntu:14.04,(ubuntu)&&(!ubuntu-us1)&&(!ubuntu-eu2)&&(!qnode3)&&(!H23) #4527

[Tomek Janiszewski]

Yeah, I know.
I was trying to remove wrapper as suggested but it didn't help. We can run
this tests separately or ignore them on ARM. I hope I manage to investigate
it last week of December.

pt., 1.12.2017, 22:06 użytkownik Vinod Kone  napisał:

> This makes me sad. Does anyone have cycles to investigate and fix this? I'm
> swamped for the next couple weeks unfortunately :(
>
> On Fri, Dec 1, 2017 at 7:53 AM, Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
> > See  > autotools,COMPILER=clang,CONFIGURATION=--verbose%20--
> > disable-libtool-wrappers,ENVIRONMENT=GLOG_v=1%20MESOS_
> > VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(ubuntu)&&(!ubuntu-
> >
> us1)&&(!ubuntu-eu2)&&(!qnode3)&&(!H23)/4527/display/redirect?page=changes>
> >
> > Changes:
> >
> > [mpark] Fixed inconsistent naming in index sequence.
> >
> > --
> > [...truncated 821.85 KB...]
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Call.Type.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.CallOrBuilder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.Builder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.Error.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.Error.Builder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.ErrorOrBuilder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.Failure.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.Failure.Builder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.FailureOrBuilder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.InverseOffers.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.InverseOffers.Builder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.InverseOffersOrBuilder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.Message.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.Message.Builder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.MessageOrBuilder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.OfferOperationUpdate.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.OfferOperationUpdate.Builder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.OfferOperationUpdateOrBuilder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.Offers.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.Offers.Builder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.OffersOrBuilder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.Rescind.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.Rescind.Builder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.RescindInverseOffer.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.RescindInverseOffer.Builder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.RescindInverseOfferOrBuilder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.RescindOrBuilder.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.Subscribed.html...
> > Generating /mesos/mesos-1.5.0/_build/src/java/target/apidocs/org/
> > apache/mesos/scheduler/Protos.Event.Subscribed.Builder.html...
> > Generating /mesos/mesos-1.5.0/_

Re: Flaky executor tests on ARM

[Tomek Janiszewski]

Disabling wrapper does not help on ARM. I need to investigate it further.

../configure --disable-java --disable-python --disable-libtool-wrapper
GTEST_FILTER=*ExecutorCheckTest.* make check -j15
[ FAILED ] 5 tests, listed below:
[ FAILED ] CommandExecutorCheckTest.CommandCheckDeliveredAndReconciled
[ FAILED ] DefaultExecutorCheckTest.CommandCheckDeliveredAndReconciled
[ FAILED ] DefaultExecutorCheckTest.CommandCheckStatusChange
[ FAILED ] DefaultExecutorCheckTest.CommandCheckSeesParentsEnv
[ FAILED ] DefaultExecutorCheckTest.CommandCheckSharesWorkDirWithTask

pt., 24 lis 2017 o 00:45 użytkownik Tomek Janiszewski 
napisał:

> Thanks, I'll take a look at this after the weekend.
>
> pt., 24.11.2017, 00:35 użytkownik Alex Rukletsov 
> napisał:
>
>> Might be libtool wrappers. Have a look at [1] and commits [2, 3, 4].
>>
>> [1] https://issues.apache.org/jira/browse/MESOS-7500
>> [2]
>>
>> https://github.com/apache/mesos/commit/d863620e5cb82b7f22cade0da0a0d18afbdf9136
>> [3]
>>
>> https://github.com/apache/mesos/commit/74121798f24fca372180b8c4bc00b4df07d46240
>> [4]
>>
>> https://github.com/apache/mesos/commit/cd516ab65b03045dba7f1cbfd40e72a1d5267539
>>
>> On Thu, Nov 23, 2017 at 11:39 AM, Tomek Janiszewski 
>> wrote:
>>
>> > Hi
>> >
>> > I found following 5 tests are flaky. They fail when run together but
>> pass
>> > alone.
>> >
>> > CommandExecutorCheckTest.CommandCheckDeliveredAndReconciled
>> > DefaultExecutorCheckTest.CommandCheckDeliveredAndReconciled
>> > DefaultExecutorCheckTest.CommandCheckStatusChange
>> > DefaultExecutorCheckTest.CommandCheckSeesParentsEnv
>> > DefaultExecutorCheckTest.CommandCheckSharesWorkDirWithTask
>> >
>> > Before I start debugging it, have you got any ideas what could be a
>> > problem?
>> >
>> > Thanks
>> > Tomek
>> >
>>
>

Re: Flaky executor tests on ARM

[Tomek Janiszewski]

Thanks, I'll take a look at this after the weekend.

pt., 24.11.2017, 00:35 użytkownik Alex Rukletsov 
napisał:

> Might be libtool wrappers. Have a look at [1] and commits [2, 3, 4].
>
> [1] https://issues.apache.org/jira/browse/MESOS-7500
> [2]
>
> https://github.com/apache/mesos/commit/d863620e5cb82b7f22cade0da0a0d18afbdf9136
> [3]
>
> https://github.com/apache/mesos/commit/74121798f24fca372180b8c4bc00b4df07d46240
> [4]
>
> https://github.com/apache/mesos/commit/cd516ab65b03045dba7f1cbfd40e72a1d5267539
>
> On Thu, Nov 23, 2017 at 11:39 AM, Tomek Janiszewski 
> wrote:
>
> > Hi
> >
> > I found following 5 tests are flaky. They fail when run together but pass
> > alone.
> >
> > CommandExecutorCheckTest.CommandCheckDeliveredAndReconciled
> > DefaultExecutorCheckTest.CommandCheckDeliveredAndReconciled
> > DefaultExecutorCheckTest.CommandCheckStatusChange
> > DefaultExecutorCheckTest.CommandCheckSeesParentsEnv
> > DefaultExecutorCheckTest.CommandCheckSharesWorkDirWithTask
> >
> > Before I start debugging it, have you got any ideas what could be a
> > problem?
> >
> > Thanks
> > Tomek
> >
>

Flaky executor tests on ARM

[Tomek Janiszewski]

Hi

I found following 5 tests are flaky. They fail when run together but pass
alone.

CommandExecutorCheckTest.CommandCheckDeliveredAndReconciled
DefaultExecutorCheckTest.CommandCheckDeliveredAndReconciled
DefaultExecutorCheckTest.CommandCheckStatusChange
DefaultExecutorCheckTest.CommandCheckSeesParentsEnv
DefaultExecutorCheckTest.CommandCheckSharesWorkDirWithTask

Before I start debugging it, have you got any ideas what could be a problem?

Thanks
Tomek

Re: .deb packages of mesos releases

[Tomek Janiszewski]

That will be awesome. We have ARM Jenkins agent so we can prepare packages
for ARM too.

wt., 14.11.2017, 23:56 użytkownik Kapil Arya  napisał:

> Hi Adam,
>
> I am wondering if you would have some time to bring your debian packaging
> into Mesos source tree. We can then use the ASF Jenkins CI to build and
> publish packages to bintray just like we started doing for CentOS 6/7? This
> will also allow the community to more actively participate in maintaining
> it in future.
>
> Best,
> Kapil
>
> On Wed, Sep 13, 2017 at 2:08 PM, Adam Cécile  wrote:
>
> > In case someone's interrested in, I added 1.1.3 debs on my repository:
> >
> > https://packages.le-vert.net/mesos/
> >
> >
> > On 09/09/2017 06:40 PM, Adam Cecile wrote:
> >
> > Hey,
> >
> > Well that's not really a problem, I can provide 1.1.x packages if your
> > interested in.
> >
> > Regards, Adam.
> >
> > On September 8, 2017 10:47:23 AM GMT+02:00, Tomek Janiszewski
> >   wrote:
> >>
> >> @Adam Thanks for taking care of this. There is one problem, Mesos 1.1.3
> >> is missing in provided repository.
> >>
> >> @Kapil What is the status of official Apache Mesos packages? At Mesos
> >> Developer Community Meeting (Jan 26, 2017) you presented a proposal for
> >> this: https://youtu.be/m7WzKia68Rg
> >>
> >> wt., 5 wrz 2017 o 15:31 użytkownik Adam Cecile 
> >> napisał:
> >>
> >>> On 09/05/2017 11:55 AM, Oskar Jagodziński wrote:
> >>> > Hi all,
> >>> >
> >>> > What is standard interval between release of mesos package and
> >>> > 'official' .deb build by Mesosphere? Mesos 1.1.3 was released 11 days
> >>> > ago and there is no package at
> >>> > https://open.mesosphere.com/downloads/mesos/ only rc-packages
> >>> > https://open.mesosphere.com/downloads/mesos-rc/ are up to date.
> >>> >
> >>> Hello,
> >>>
> >>>
> >>> First, I like to make an important statement:
> >>>
> >>> *I'm not an official mesosphere guy*
> >>>
> >>> That being said, Mesosphere package are binary copy of CentOS built
> file
> >>> into a deb container. That's not what I call a Debian package at all
> and
> >>> I already had severe issue with that (libcurl-nss backed built which
> >>> does not support https on Debian-based system).
> >>>
> >>> For this reason, I create my own Mesos package, as a REAL debian
> >>> package, built from sources in a clean environment using pbuilder. I
> >>> also provide armhf and arm64 build because I've plan for that ;-)
> >>>
> >>> These package are in-use at three customers place and work just fine. I
> >>> provide multiple branches packages and build them with additional
> >>> network isolator using libnl and XFS disk isolator.
> >>>
> >>>
> >>> It's available there:
> >>>
> >>> https://packages.le-vert.net/mesos/
> >>>
> >>> Feel free to do what the f*** you want, use the repository directly,
> >>> sync it, rebuild debs from sources packages...
> >>>
> >>>
> >>> Regards, Adam.
> >>>
> >>>
> > --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >
> >
> >
>

Re: Sandbox life cycle /age

[Tomek Janiszewski]

Low GC delay menas files will be deleted more often. I don't' think there
will be any performance problem but low GC means you will lose your
sandboxes earlier and they are useful for debugging purposes.

pt., 27 paź 2017 o 04:40 użytkownik Venkat Morampudi <
venkatmoramp...@gmail.com> napisał:

> Hi Tomek,
>
> Thanks for the quick reply. After digging a bit into Mesos code we were
> able understand that age actually mean threshold age. Anything older than
> the “age" would be GCed. We are going to try different setting starting
> with "--gc_disk_headroom=.2 --gc_delay=2hrs”. Is there any downside of the
> going with very low GC delay?
>
> Thanks,
> Venkat
>
>
> > On Oct 26, 2017, at 4:28 PM, Tomek Janiszewski 
> wrote:
> >
> >> gc_delay * max(0.0, (1.0 - gc_disk_headroom - disk usage))
> >
> > *Example:*
> > gc_delay = 7days
> > gc_disk_headroom = 0.1
> > disk_usage = 0.8
> > 7 * max(0.0, 1 - 0.1 - 0.8) = 7 * max(0.0, 0.1) = 0.7 days = 16 h 48 min
> >
> > Can you show some logs containging information about GC?
> >
> > pt., 27 paź 2017 o 00:43 użytkownik Venkat Morampudi <
> > venkatmoramp...@gmail.com <mailto:venkatmoramp...@gmail.com>> napisał:
> >
> >> Hello,
> >> In our production env, we noticed that our disk filled up because one
> >> framework had a lot of failed/completed executors folders laying around.
> >> The folders eventually filled up the disk.
> >>
> >>
> >> 228M
> >>
> /mnt/resource/slaves/c8674097-6e67-4609-b022-3e11de380fe5-S2/frameworks/35e600c2-6f43-402c-856f-9084c0040187-002/executors/52334.1.0
> >> 228M
> >>
> /mnt/resource/slaves/c8674097-6e67-4609-b022-3e11de380fe5-S2/frameworks/35e600c2-6f43-402c-856f-9084c0040187-002/executors/52334.2.0
> >> 228M
> >>
> /mnt/resource/slaves/c8674097-6e67-4609-b022-3e11de380fe5-S2/frameworks/35e600c2-6f43-402c-856f-9084c0040187-002/executors/52335.1.0
> >> 228M
> >>
> /mnt/resource/slaves/c8674097-6e67-4609-b022-3e11de380fe5-S2/frameworks/35e600c2-6f43-402c-856f-9084c0040187-002/executors/52335.2.0
> >> 228M
> >>
> /mnt/resource/slaves/c8674097-6e67-4609-b022-3e11de380fe5-S2/frameworks/35e600c2-6f43-402c-856f-9084c0040187-002/executors/52336.1.0
> >>
> >> http://mesos.apache.org/documentation/latest/sandbox/#sandbox-lifecycle
> <
> >> http://mesos.apache.org/documentation/latest/sandbox/#sandbox-lifecycle
> <http://mesos.apache.org/documentation/latest/sandbox/#sandbox-lifecycle>>
> >>
> >> We have our lifecycle clean up set to the default which is 7days, I
> >> believe.
> >>
> >> We wanted to know if this is the proper way to clean up the
> >> failed/completed executors folders for a running framework?
> >> OR does the framework need to be Inactive or Completed for the garbage
> >> collection to work?
> >> OR does the framework , itself, need to deal with cleaning up its own
> >> executors?
> >>
> >> Bonus question: How does “gc_disk_headroom” actually work? This equation
> >> will always return 0 it seems. gc_delay * max(0.0, (1.0 -
> gc_disk_headroom
> >> - disk usage))
> >>
> >> Thanks,
> >> Venkat
>
>

Re: Sandbox life cycle /age

[Tomek Janiszewski]

>  gc_delay * max(0.0, (1.0 - gc_disk_headroom - disk usage))

*Example:*
gc_delay = 7days
gc_disk_headroom = 0.1
disk_usage = 0.8
7 * max(0.0, 1 - 0.1 - 0.8) = 7 * max(0.0, 0.1) = 0.7 days = 16 h 48 min

Can you show some logs containging information about GC?

pt., 27 paź 2017 o 00:43 użytkownik Venkat Morampudi <
venkatmoramp...@gmail.com> napisał:

> Hello,
> In our production env, we noticed that our disk filled up because one
> framework had a lot of failed/completed executors folders laying around.
> The folders eventually filled up the disk.
>
>
> 228M
> /mnt/resource/slaves/c8674097-6e67-4609-b022-3e11de380fe5-S2/frameworks/35e600c2-6f43-402c-856f-9084c0040187-002/executors/52334.1.0
> 228M
> /mnt/resource/slaves/c8674097-6e67-4609-b022-3e11de380fe5-S2/frameworks/35e600c2-6f43-402c-856f-9084c0040187-002/executors/52334.2.0
> 228M
> /mnt/resource/slaves/c8674097-6e67-4609-b022-3e11de380fe5-S2/frameworks/35e600c2-6f43-402c-856f-9084c0040187-002/executors/52335.1.0
> 228M
> /mnt/resource/slaves/c8674097-6e67-4609-b022-3e11de380fe5-S2/frameworks/35e600c2-6f43-402c-856f-9084c0040187-002/executors/52335.2.0
> 228M
> /mnt/resource/slaves/c8674097-6e67-4609-b022-3e11de380fe5-S2/frameworks/35e600c2-6f43-402c-856f-9084c0040187-002/executors/52336.1.0
>
> http://mesos.apache.org/documentation/latest/sandbox/#sandbox-lifecycle <
> http://mesos.apache.org/documentation/latest/sandbox/#sandbox-lifecycle>
>
> We have our lifecycle clean up set to the default which is 7days, I
> believe.
>
> We wanted to know if this is the proper way to clean up the
> failed/completed executors folders for a running framework?
> OR does the framework need to be Inactive or Completed for the garbage
> collection to work?
> OR does the framework , itself, need to deal with cleaning up its own
> executors?
>
> Bonus question: How does “gc_disk_headroom” actually work? This equation
> will always return 0 it seems. gc_delay * max(0.0, (1.0 - gc_disk_headroom
> - disk usage))
>
> Thanks,
> Venkat
>
>

Re: [Proposal] Mesos on ARM

[Tomek Janiszewski]

@Matt I think Java runs on ARM and I saw some fixes for Zookeeper on ARM so
the main problem in running DC/OS is Mesos. Maybe there are other
components that might need to be fixed.

@Brock Thanks for interest. If you encourage any issue with ARM please ping
me. You can also report it on Apache JIRA with arm64 label.

wt., 26 wrz 2017 o 16:36 użytkownik Matt Jarvis 
napisał:

> As a stretch goal, I'd also be interested in understanding what's required
> to run the rest of DC/OS on ARM - action is on me to reach out to the
> relevant folks inside Mesosphere for that.
>
> On 26 September 2017 at 14:39, Tomek Janiszewski 
> wrote:
>
>> Hi all
>>
>> I'd like to propose to add ARM64 support in Mesos. Currently, the only
>> Agent can run on ARM but it's not officially supported. This means build
>> failures on ARM are not considered as a bug.
>>
>> I know there were a couple of tries to run Mesos on ARM (mostly on
>> Raspberry PI) but this process is not straightforward and requires some
>> tuning.
>>
>> I'd like, in cooperation with WorksOnArm, to add ARM-based build to our
>> required test suit. Before, we need to make code to build on ARM and pass
>> all tests.
>>
>> Unfortunately, I do not know what exactly needs to be fixed because I
>> haven't started yet. I hope we can do it step by step. Once we got ARM
>> server we can use it to find problems when running on this architecture.
>>
>> What do you think about this? Is anybody interested in running Mesos on
>> ARM?
>>
>>
>> https://docs.google.com/document/d/1Hs40tGSUyoQa78ifVvn7VO5iSqe8nMc7VYWSugOqGFw/edit?usp=sharing
>> https://github.com/WorksOnArm/cluster/issues/9
>>
>> Thanks!
>>
>> –
>> Tomasz Janiszewski
>>
>
>

[Proposal] Mesos on ARM

[Tomek Janiszewski]

Hi all

I'd like to propose to add ARM64 support in Mesos. Currently, the only
Agent can run on ARM but it's not officially supported. This means build
failures on ARM are not considered as a bug.

I know there were a couple of tries to run Mesos on ARM (mostly on
Raspberry PI) but this process is not straightforward and requires some
tuning.

I'd like, in cooperation with WorksOnArm, to add ARM-based build to our
required test suit. Before, we need to make code to build on ARM and pass
all tests.

Unfortunately, I do not know what exactly needs to be fixed because I
haven't started yet. I hope we can do it step by step. Once we got ARM
server we can use it to find problems when running on this architecture.

What do you think about this? Is anybody interested in running Mesos on ARM?

https://docs.google.com/document/d/1Hs40tGSUyoQa78ifVvn7VO5iSqe8nMc7VYWSugOqGFw/edit?usp=sharing
https://github.com/WorksOnArm/cluster/issues/9

Thanks!

–
Tomasz Janiszewski

Re: protbuf to json not compatible

[Tomek Janiszewski]

I have a similar problem with protobuf and json. In my case numbers were
incorrectly unmarshaled. Here is an issue
https://issues.apache.org/jira/browse/MESOS-970 and review
https://reviews.apache.org/r/50851/

czw., 23.03.2017, 09:54 użytkownik Olivier Sallou 
napisał:

> Hi,
>
> when transforming a protobug message to json with MessageToJson, the
> json is not compatible with the json format expected by Mesos master.
>
> For example, for volumes it generates
>
>
> volumes: [
>
> {'hostPath': '',
>
>   'containerPath': '...',
>
>  ...
>
>}
>
> ]
>
>
> but HTTP API expects "source" and "container_path"
>
> is it an expected behavior ? This prevents from "creating" a task in
> protobuf format and sending it to HTTP API with a protobug to json
> conversion.
>
> Thanks
>
> Olivier
>
> --
> Olivier Sallou
> IRISA / University of Rennes 1
> Campus de Beaulieu, 35000 RENNES - FRANCE
> Tel: 02.99.84.71.95
>
> gpg key id: 4096R/326D8438  (keyring.debian.org)
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438
>
>

Re: MESOS-7233: Looking for shepherd

[Tomek Janiszewski]

OK, I discovered it myself, this test uses absolute paths.

@Benjamin You were right it's not backward compatible. I'll work on this.

mesos 1.3.0 framework failed with mesos 1.3.48291 master and mesos 1.3.0
agent




pt., 17 mar 2017 o 13:44 użytkownik Tomek Janiszewski 
napisał:

@Benjamin thanks for taking a look at this. I tried to run
mesos/test-upgrade.py but it failed on starting the framework? Below are
the logs? What am I doing wrong?

./support/test-upgrade.py --prev build --next build-varint
Running upgrade test from mesos 1.3.0 to mesos 1.3.0
+--+++---+
| Test case|   Framework| Master | Agent |
+--+++---+
|#1|  mesos 1.3.0 | mesos 1.3.0 | mesos 1.3.0 |
|#2|  mesos 1.3.0 | mesos 1.3.0 | mesos 1.3.0 |
|#3|  mesos 1.3.0 | mesos 1.3.0 | mesos 1.3.0 |
|#4|  mesos 1.3.0 | mesos 1.3.0 | mesos 1.3.0 |
+--+++---+

NOTE: live denotes that master process keeps running from previous case.


Test case 1 (Run of previous setup)
# Starting mesos 1.3.0 master #
Run ['build/bin/mesos-master.sh', '--ip=127.0.0.1',
'--work_dir=/tmp/tmpGs3TLW', '--authenticate',
'--credentials=/tmp/tmpQUicSA', '--roles=test'], output: /tmp/tmpSVfW1x
# Starting mesos 1.3.0 agent #
Run ['build/bin/mesos-slave.sh', '--master=127.0.0.1:5050',
'--credential=/tmp/tmpQUicSA', '--work_dir=/tmp/tmpCgaNrV',
'--resources=disk:2048;mem:2048;cpus:2'], output: /tmp/tmpgil1QV
# Starting mesos 1.3.0 framework #
Waiting for mesos 1.3.0 framework to complete (10 sec max)...
Run ['build/src/test-framework', '--master=127.0.0.1:5050'], output:
/tmp/tmp_sTAa1
mesos 1.3.0 framework failed


pt., 17 mar 2017 o 00:44 użytkownik Benjamin Mahler 
napisał:

Thanks Tomek, I'm not very familiar with the code but I dug in and couldn't
figure out how this is a backwards compatible change to make. Left a
comment on the review.

On Sat, Mar 11, 2017 at 2:24 AM, Tomek Janiszewski 
wrote:

> Hi
>
> I'm looking for shepherd for MESOS-7233 — Use varint comparator in replica
> log.
>
> JIRA: https://issues.apache.org/jira/browse/MESOS-7233
> Review: https://reviews.apache.org/r/48291/
>
> Thanks
> Tomek
>

Re: MESOS-7233: Looking for shepherd

[Tomek Janiszewski]

@Benjamin thanks for taking a look at this. I tried to run
mesos/test-upgrade.py but it failed on starting the framework? Below are
the logs? What am I doing wrong?

./support/test-upgrade.py --prev build --next build-varint
Running upgrade test from mesos 1.3.0 to mesos 1.3.0
+--+++---+
| Test case|   Framework| Master | Agent |
+--+++---+
|#1|  mesos 1.3.0 | mesos 1.3.0 | mesos 1.3.0 |
|#2|  mesos 1.3.0 | mesos 1.3.0 | mesos 1.3.0 |
|#3|  mesos 1.3.0 | mesos 1.3.0 | mesos 1.3.0 |
|#4|  mesos 1.3.0 | mesos 1.3.0 | mesos 1.3.0 |
+--+++---+

NOTE: live denotes that master process keeps running from previous case.


Test case 1 (Run of previous setup)
# Starting mesos 1.3.0 master #
Run ['build/bin/mesos-master.sh', '--ip=127.0.0.1',
'--work_dir=/tmp/tmpGs3TLW', '--authenticate',
'--credentials=/tmp/tmpQUicSA', '--roles=test'], output: /tmp/tmpSVfW1x
# Starting mesos 1.3.0 agent #
Run ['build/bin/mesos-slave.sh', '--master=127.0.0.1:5050',
'--credential=/tmp/tmpQUicSA', '--work_dir=/tmp/tmpCgaNrV',
'--resources=disk:2048;mem:2048;cpus:2'], output: /tmp/tmpgil1QV
# Starting mesos 1.3.0 framework #
Waiting for mesos 1.3.0 framework to complete (10 sec max)...
Run ['build/src/test-framework', '--master=127.0.0.1:5050'], output:
/tmp/tmp_sTAa1
mesos 1.3.0 framework failed


pt., 17 mar 2017 o 00:44 użytkownik Benjamin Mahler 
napisał:

> Thanks Tomek, I'm not very familiar with the code but I dug in and couldn't
> figure out how this is a backwards compatible change to make. Left a
> comment on the review.
>
> On Sat, Mar 11, 2017 at 2:24 AM, Tomek Janiszewski 
> wrote:
>
> > Hi
> >
> > I'm looking for shepherd for MESOS-7233 — Use varint comparator in
> replica
> > log.
> >
> > JIRA: https://issues.apache.org/jira/browse/MESOS-7233
> > Review: https://reviews.apache.org/r/48291/
> >
> > Thanks
> > Tomek
> >
>

MESOS-7233: Looking for shepherd

[Tomek Janiszewski]

Hi

I'm looking for shepherd for MESOS-7233 — Use varint comparator in replica
log.

JIRA: https://issues.apache.org/jira/browse/MESOS-7233
Review: https://reviews.apache.org/r/48291/

Thanks
Tomek

Re: mesos git commit: Upgrade leveldb to 1.19.

[Tomek Janiszewski]

I run benchmarks and the results are here
https://gist.github.com/janisz/5d2585376fc8ffb6d0fa9bb25afc7b92



pon., 20 lut 2017 o 19:01 użytkownik haosdent  napisał:

> Thanks a lot for jie's great help. Create two tickets at
>
> https://issues.apache.org/jira/browse/MESOS-7147
> https://issues.apache.org/jira/browse/MESOS-7148
>
> Hopefully we would finish them in the following days to get the benchmark
> result.
> If the result shows leveldb 1.19 make the benchmark worst, I would revert
> the changes as the following step.
>
> On Tue, Feb 21, 2017 at 1:39 AM, Jie Yu  wrote:
>
> > Thanks Tomek!
> >
> > I don't think we have BENCHMARK test for replicated log, which uses
> leveldb
> > as its backend. We do have tools built to do manual testing.
> >
> > ```
> > Jies-MacBook-Pro:bin jie$ ./mesos-log --help
> > Cannot find command '--help'
> >
> > Usage: ./mesos-log  [OPTIONS]
> >
> > Available commands:
> > help
> > replica
> > read
> > initialize
> > benchmark
> > ```
> >
> > The `replica` command will launch a replica of the replicated log. The
> > `benchmark` will generate writes (either random or based on a trace) to
> the
> > replicated log, and report time. I think we should run this manually
> before
> > and after applying the patch to evaluate the write performance.
> >
> > We probably should add a BENCHMARK test to our test suite so that this
> can
> > be automated. For instance, initialize a replicated log with a single
> > replica, and perform a bunch of writes with random sizes.
> >
> > - Jie
> >
> >
> >
> > On Mon, Feb 20, 2017 at 3:13 AM, Tomek Janiszewski 
> > wrote:
> >
> > > Test summary and comparison between 1.4 and 1.19
> > > https://docs.google.com/document/d/1fv2OMvH6hVm6waacOejSrTJwUuDQe
> > > XlqqPDZjBmbcKU/edit#heading=h.ewfisffoslz3
> > >
> > > pon., 20 lut 2017 o 11:28 użytkownik Jie Yu 
> > napisał:
> > >
> > > > Do we have some benchmark numbers to vet this change? We have some
> > > > replicated log benchmarks.
> > > >
> > > > Sent from my iPhone
> > > >
> > > > > On Feb 19, 2017, at 11:37 PM, haosd...@apache.org wrote:
> > > > >
> > > > > Repository: mesos
> > > > > Updated Branches:
> > > > >  refs/heads/master 86ea327ae -> 74878e255
> > > > >
> > > > >
> > > > > Upgrade leveldb to 1.19.
> > > > >
> > > > > Leveldb in modern version is required to support s390x and arm64.
> > > > > It's also required to replace default byte-wise comparator with
> > > > > varint comparator in `src/log/leveldb.cpp`.
> > > > >
> > > > > Review: https://reviews.apache.org/r/51053/
> > > > >
> > > > >
> > > > > Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
> > > > > Commit:
> http://git-wip-us.apache.org/repos/asf/mesos/commit/74878e25
> > > > > Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/74878e25
> > > > > Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/74878e25
> > > > >
> > > > > Branch: refs/heads/master
> > > > > Commit: 74878e255bb099029dde2a03e0b1d22fecf16000
> > > > > Parents: 86ea327
> > > > > Author: Tomasz Janiszewski 
> > > > > Authored: Mon Feb 20 12:24:44 2017 +0800
> > > > > Committer: Haosdent Huang 
> > > > > Committed: Mon Feb 20 15:36:54 2017 +0800
> > > > >
> > > > > 
> > --
> > > > > 3rdparty/Makefile.am|   4 +-
> > > > > 3rdparty/cmake/Mesos3rdpartyConfigure.cmake |   2 +-
> > > > > 3rdparty/cmake/Versions.cmake   |   2 +-
> > > > > 3rdparty/leveldb-1.19.patch |  30 
> > > > > 3rdparty/leveldb-1.19.tar.gz| Bin 0 -> 220839 bytes
> > > > > 3rdparty/leveldb-1.4.patch  |  57
> > > ---
> > > > > 3rdparty/leveldb-1.4.tar.gz | Bin 198113 -> 0 bytes
> > > > > 3rdparty/versions.am|   2 +-
> > > > > LICENSE |   2 +-
> > > > > src/Makefile.am |

Re: mesos git commit: Upgrade leveldb to 1.19.

[Tomek Janiszewski]

Test summary and comparison between 1.4 and 1.19
https://docs.google.com/document/d/1fv2OMvH6hVm6waacOejSrTJwUuDQeXlqqPDZjBmbcKU/edit#heading=h.ewfisffoslz3

pon., 20 lut 2017 o 11:28 użytkownik Jie Yu  napisał:

> Do we have some benchmark numbers to vet this change? We have some
> replicated log benchmarks.
>
> Sent from my iPhone
>
> > On Feb 19, 2017, at 11:37 PM, haosd...@apache.org wrote:
> >
> > Repository: mesos
> > Updated Branches:
> >  refs/heads/master 86ea327ae -> 74878e255
> >
> >
> > Upgrade leveldb to 1.19.
> >
> > Leveldb in modern version is required to support s390x and arm64.
> > It's also required to replace default byte-wise comparator with
> > varint comparator in `src/log/leveldb.cpp`.
> >
> > Review: https://reviews.apache.org/r/51053/
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/74878e25
> > Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/74878e25
> > Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/74878e25
> >
> > Branch: refs/heads/master
> > Commit: 74878e255bb099029dde2a03e0b1d22fecf16000
> > Parents: 86ea327
> > Author: Tomasz Janiszewski 
> > Authored: Mon Feb 20 12:24:44 2017 +0800
> > Committer: Haosdent Huang 
> > Committed: Mon Feb 20 15:36:54 2017 +0800
> >
> > --
> > 3rdparty/Makefile.am|   4 +-
> > 3rdparty/cmake/Mesos3rdpartyConfigure.cmake |   2 +-
> > 3rdparty/cmake/Versions.cmake   |   2 +-
> > 3rdparty/leveldb-1.19.patch |  30 
> > 3rdparty/leveldb-1.19.tar.gz| Bin 0 -> 220839 bytes
> > 3rdparty/leveldb-1.4.patch  |  57 ---
> > 3rdparty/leveldb-1.4.tar.gz | Bin 198113 -> 0 bytes
> > 3rdparty/versions.am|   2 +-
> > LICENSE |   2 +-
> > src/Makefile.am |   2 +-
> > src/python/native_common/ext_modules.py.in  |   4 +-
> > support/mesos-tidy/entrypoint.sh|   2 +-
> > 12 files changed, 40 insertions(+), 67 deletions(-)
> > --
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/mesos/blob/74878e25/3rdparty/Makefile.am
> > --
> > diff --git a/3rdparty/Makefile.am b/3rdparty/Makefile.am
> > index bbf9cfe..61d832b2 100644
> > --- a/3rdparty/Makefile.am
> > +++ b/3rdparty/Makefile.am
> > @@ -296,11 +296,11 @@ BUILT_SOURCES += $(nodist_libgmock_la_SOURCES)
> > if WITH_BUNDLED_LEVELDB
> > # TODO(charles): Figure out PIC options in our configure.ac or create
> > # a configure.ac for leveldb.
> > -$(LEVELDB)/libleveldb.a: $(LEVELDB)-stamp
> > +$(LEVELDB)/out-static/libleveldb.a: $(LEVELDB)-stamp
> >cd $(LEVELDB) && \
> >  $(MAKE) $(AM_MAKEFLAGS) CC="$(CC)" CXX="$(CXX)" OPT="$(CXXFLAGS)
> -fPIC"
> >
> > -ALL_LOCAL += $(LEVELDB)/libleveldb.a
> > +ALL_LOCAL += $(LEVELDB)/out-static/libleveldb.a
> > endif
> >
> > if WITH_BUNDLED_ZOOKEEPER
> >
> >
> http://git-wip-us.apache.org/repos/asf/mesos/blob/74878e25/3rdparty/cmake/Mesos3rdpartyConfigure.cmake
> > --
> > diff --git a/3rdparty/cmake/Mesos3rdpartyConfigure.cmake
> b/3rdparty/cmake/Mesos3rdpartyConfigure.cmake
> > index eeb2786..c606526 100755
> > --- a/3rdparty/cmake/Mesos3rdpartyConfigure.cmake
> > +++ b/3rdparty/cmake/Mesos3rdpartyConfigure.cmake
> > @@ -47,7 +47,7 @@ endif (NOT WIN32)
> > # Convenience variables for "lflags", the symbols we pass to CMake to
> generate
> > # things like `-L/path/to/glog` or `-lglog`.
> > if (NOT WIN32)
> > -  set(LEVELDB_LFLAG   ${LEVELDB_ROOT}/libleveldb.a)
> > +  set(LEVELDB_LFLAG   ${LEVELDB_ROOT}/out-static/libleveldb.a)
> >   set(ZOOKEEPER_LFLAG ${ZOOKEEPER_LIB}/lib/libzookeeper_mt.a)
> > else (NOT WIN32)
> >   set(ZOOKEEPER_LFLAG zookeeper)
> >
> >
> http://git-wip-us.apache.org/repos/asf/mesos/blob/74878e25/3rdparty/cmake/Versions.cmake
> > --
> > diff --git a/3rdparty/cmake/Versions.cmake
> b/3rdparty/cmake/Versions.cmake
> > index ad23f38..9127263 100644
> > --- a/3rdparty/cmake/Versions.cmake
> > +++ b/3rdparty/cmake/Versions.cmake
> > @@ -4,7 +4,7 @@ set(ELFIO_VERSION   "3.2")
> > set(GLOG_VERSION"0.3.3")
> > set(GMOCK_VERSION   "1.7.0")
> > set(HTTP_PARSER_VERSION "2.6.2")
> > -set(LEVELDB_VERSION "1.4")
> > +set(LEVELDB_VERSION "1.19")
> > set(LIBAPR_VERSION  "1.5.2")
> > set(LIBEV_VERSION   "4.22")
> > # TODO(hausdorff): (MESOS-3529) transition this back to a non-beta
> version.
> >
> >
> http://git-wip-us.apache.org/repos/asf/mesos/blob/74878e25/3rdparty/leveldb-1.19.patch
> > --
> > diff --git a/3rdpart

Re: Mesos-go status

[Tomek Janiszewski]

Thanks, glide will solve packaging problem. Nevertheless, if mesos-go is
dead we should bring it back to live or disable PRs and issues and add
comment that this repo is no longer maintained e.g.,
https://github.com/mesosphere/marathon-ui#project-status

pt., 3 lut 2017 o 16:00 użytkownik Jake Farrell 
napisał:

> You do not necessarily have to repackage, if you are using glide [1] to
> build your application you can specify a package like
> github.com/mesos/mesos-go and then specify your fork as the repo to check
> out and glide will automatically place the fork into that package namespace
> for you.
>
> -Jake
>
>
> [1]: https://glide.readthedocs.io/en/latest/glide.yaml/
>
> On Fri, Feb 3, 2017 at 6:54 AM, Tomek Janiszewski 
> wrote:
>
> > I know but I'd prefer to avoid to double work that somebody have already
> > done. If I fork it and made custom changes (in Go this require
> repackaging)
> > I'll end up with my custom fork that only I'm interested in with no
> support
> > from community. See this comment[1] with one repo we have two nearly
> > identical pull requests. If I create custom fork I'll totally lose a
> track
> > with others. And it's possible I'll duplicate work somebody already did
> and
> > hit the bugs that already was resolved.
> >
> > [1]: https://github.com/mesos/mesos-go/pull/262#issuecomment-246865392
> >
> > pt., 3 lut 2017 o 12:31 użytkownik tommy xiao 
> napisał:
> >
> > > you can forked it>>>
> > >
> > > 2017-02-03 18:43 GMT+08:00 Tomek Janiszewski :
> > >
> > > > Hi
> > > >
> > > > What is the status of https://github.com/mesos/mesos-go It looks
> like
> > > it's
> > > > abandoned. Useful pull requests are awaiting merge and issues need to
> > be
> > > > fixed. Who is the owner of this repo? I can volunteer to continue
> this
> > > > project especially the executor module.
> > > >
> > > > Thanks
> > > > Tomek
> > > >
> > >
> > >
> > >
> > > --
> > > Deshi Xiao
> > > Twitter: xds2000
> > > E-mail: xiaods(AT)gmail.com
> > >
> >
>

Re: Mesos-go status

[Tomek Janiszewski]

I know but I'd prefer to avoid to double work that somebody have already
done. If I fork it and made custom changes (in Go this require repackaging)
I'll end up with my custom fork that only I'm interested in with no support
from community. See this comment[1] with one repo we have two nearly
identical pull requests. If I create custom fork I'll totally lose a track
with others. And it's possible I'll duplicate work somebody already did and
hit the bugs that already was resolved.

[1]: https://github.com/mesos/mesos-go/pull/262#issuecomment-246865392

pt., 3 lut 2017 o 12:31 użytkownik tommy xiao  napisał:

> you can forked it>>>
>
> 2017-02-03 18:43 GMT+08:00 Tomek Janiszewski :
>
> > Hi
> >
> > What is the status of https://github.com/mesos/mesos-go It looks like
> it's
> > abandoned. Useful pull requests are awaiting merge and issues need to be
> > fixed. Who is the owner of this repo? I can volunteer to continue this
> > project especially the executor module.
> >
> > Thanks
> > Tomek
> >
>
>
>
> --
> Deshi Xiao
> Twitter: xds2000
> E-mail: xiaods(AT)gmail.com
>

Mesos-go status

[Tomek Janiszewski]

Hi

What is the status of https://github.com/mesos/mesos-go It looks like it's
abandoned. Useful pull requests are awaiting merge and issues need to be
fixed. Who is the owner of this repo? I can volunteer to continue this
project especially the executor module.

Thanks
Tomek

Re: Command healthcheck failed but status KILLED

[Tomek Janiszewski]

Thanks Gastón. Do we have a shepherd for this? It's not critical but make
it hard to distinguish task killed by failed health check from killed by
scheduler.

wt., 13.12.2016 o 16:55 użytkownik Gastón Kleiman 
napisał:

> On Mon, Dec 12, 2016 at 12:47 PM, Tomek Janiszewski 
> wrote:
>
> > It there any information that kill is the result of failed healthcheck?
> > TaskHealthStatus should have some details on what was wrong. When default
> > executor is killing task it should add a reason and details to
> TaskStatus.
> > What do you think?
> >
>
> I agree with you, so I created
> https://issues.apache.org/jira/browse/MESOS-6786 with some ideas.
>
> -Gastón
>

Re: [webui] Started show wrong time

[Tomek Janiszewski]

Thanks Haosdent. I described possible solution in ticket. If it's ok I can
prepare a patch.

śr., 14.12.2016 o 05:05 użytkownik haosdent  napisał:

> Hi, @Tomek. Thank you for your report. Create a ticket at
> https://issues.apache.org/jira/browse/MESOS-6790, feel free to post a
> patch
> if you have idea for it.
>
> On Wed, Dec 14, 2016 at 7:25 AM, Alex Rukletsov 
> wrote:
>
> > This looks like a bug. Tomek, could you please file a JIRA?
> >
> > On Tue, Dec 13, 2016 at 1:02 PM, Tomek Janiszewski 
> > wrote:
> >
> > > Hi
> > >
> > > When task has enabled Mesos healthcheck start time in UI can show wrong
> > > time. This happens because UI assumes that first status is task started
> > > [0]. This is not always true because Mesos keeps only recent tasks
> > statuses
> > > [1] so when healthcheck updates tasks status it can override task start
> > > time displayed in webui.
> > >
> > > Best
> > > Tomek
> > >
> > > [0]
> > > https://github.com/apache/mesos/blob/master/src/webui/
> > > master/static/js/controllers.js#L140
> > > [1]
> > > https://github.com/apache/mesos/blob/f2adc8a95afda943f6a10e771aad64
> > > 300da19047/src/common/protobuf_utils.cpp#L263-L265
> > >
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

[webui] Started show wrong time

[Tomek Janiszewski]

Hi

When task has enabled Mesos healthcheck start time in UI can show wrong
time. This happens because UI assumes that first status is task started
[0]. This is not always true because Mesos keeps only recent tasks statuses
[1] so when healthcheck updates tasks status it can override task start
time displayed in webui.

Best
Tomek

[0]
https://github.com/apache/mesos/blob/master/src/webui/master/static/js/controllers.js#L140
[1]
https://github.com/apache/mesos/blob/f2adc8a95afda943f6a10e771aad64300da19047/src/common/protobuf_utils.cpp#L263-L265

Re: Command healthcheck failed but status KILLED

[Tomek Janiszewski]

It there any information that kill is the result of failed healthcheck?
TaskHealthStatus should have some details on what was wrong. When default
executor is killing task it should add a reason and details to TaskStatus.
What do you think?

pon., 12.12.2016 o 11:11 użytkownik Alex Rukletsov 
napisał:

> Technically the task hast not failed but was killed by the executor
> (because it failed a health check).
>
> On Fri, Dec 9, 2016 at 11:27 AM, Tomek Janiszewski 
> wrote:
>
> > Hi
> >
> > What is desired behavior when command health check failed? On Mesos 1.0.2
> > when health check fails task has state KILLED instead of FAILED with
> reason
> > specifying it was killed due to failing health check.
> >
> > Thanks
> > Tomek
> >
>

Command healthcheck failed but status KILLED

[Tomek Janiszewski]

Hi

What is desired behavior when command health check failed? On Mesos 1.0.2
when health check fails task has state KILLED instead of FAILED with reason
specifying it was killed due to failing health check.

Thanks
Tomek

Re: Mesos V1 Operator HTTP API - Java Proto Classes

[Tomek Janiszewski]

I suspect jar is deprecated and includes only old API used by mesoslib. The
goal is to create HTTP API and stop supporting native libs (jars, so, etc).
I think you shouldn't use that jar in your project.

wt., 15.11.2016, 20:38 użytkownik Vijay Srinivasaraghavan <
vijikar...@yahoo.com> napisał:

> Hello,
>
> I am writing a rest client for "operator APIs" and found that some of the
> protobuf java classes (like "include/mesos/v1/quota/quota.proto",
> "include/mesos/v1/master/master.proto") are not included in the mesos jar
> file. While investigating, I have found that the "Make" file does not
> include these proto definition files.
>
> I have updated the Make file and added the protos that I am interested in
> and built a new jar file. Is there any reason why these proto definitions
> are not included in the original build apart from the reason that the APIs
> are still evolving?
>
> Regards
> Vijay
>

Re: Which service discovery mechanism could be used with mesos?

[Tomek Janiszewski]

Hi

Take a look at this SO answer http://stackoverflow.com/a/37822870/1387612

Service discovery could be Mesos agnostic by implementing
registration/quering mechanism in application. On the other hand using
discovery service that integrates with Mesos will reduce in application
code.

If you need load balancing with configurable algorithm then proxy based
solution will be good choice e.g., Traefik. DNS load balancer are hard to
configure becouse algorithm depends on client implementation (how responses
are cached and how server is chosen).

This are short answer, everything depends on use case.

Best

Tomek

pon., 7.11.2016, 11:55 użytkownik Yu Wei  napisał:

Hi Guys,


I deployed a mesos cluster with zookeeper.

Which methods could be used for service discovery and load balance?


Thanks,

Jared, (??)
Software developer
Interested in open source software, big data, Linux

Re: Features missing in the webui

[Tomek Janiszewski]

At MesosCon EU we were working on bringing Maintenance Mode to the UI.
Maintenance of nodes will be presented in a table. Code is on github but
need some tweaks and tests with large maintenance json. I'll prepare patch
shortly (when github DDoS will be over).
https://issues.apache.org/jira/browse/MESOS-6443

pt., 21.10.2016 o 20:30 użytkownik Benjamin Mahler 
napisał:

> When adding features we try to ensure the webui is updated accordingly.
> However, there have been a few gaps where the webui has not been updated to
> reflect the addition of functionality.
>
> I filed the following epic to collect gaps in functionality:
> https://issues.apache.org/jira/browse/MESOS-6440
>
> For example, one that came to mind after discussing with Zhitao is that we
> don't display the volumes present on the agent. If you know of any features
> that have been added that are missing webui updates please file a ticket
> under this epic so that we can collect them together and try to catch the
> webui up to the latest state of things.
>
> If there are any ongoing projects that warrant webui updates, don't forget
> to make webui changes as part of completing the project.
>
> Any thoughts or feedback?
>
> Ben
>

Re: Shepherd for MESOS-970

[Tomek Janiszewski]

Yes, I'm still having issues with test-upgrade.py even for lastes master
testing against itself. I checked it manually launched some tasks +
followed steps you presented in testing doc and it worked the same as for
upgrade to 1.18.

niedz., 18.09.2016 o 19:35 użytkownik haosdent  napisał:

> Hi, @janiszt. I remember you mentioned it has problems when
> use test-upgrade.py to test upgrading from leveldb 1.4 to leveldb 1.19. Is
> it still a problem now?
>
> On Mon, Sep 19, 2016 at 1:28 AM, Tomek Janiszewski 
> wrote:
>
> > Hi
> >
> > I'm looking for shephard for:
> > https://issues.apache.org/jira/browse/MESOS-970
> > Patch: https://reviews.apache.org/r/51053/
> >
> > Best
> > Tomek
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Shepherd for MESOS-970

[Tomek Janiszewski]

Hi

I'm looking for shephard for:
https://issues.apache.org/jira/browse/MESOS-970
Patch: https://reviews.apache.org/r/51053/

Best
Tomek

Re: How could Mesos work with docker?

[Tomek Janiszewski]

Hi

Docker support is described here
http://mesos.apache.org/documentation/latest/docker-containerizer/

Best
Tomek

wt., 9.08.2016 o 16:04 użytkownik Yu Wei  napisał:

> Hi guys,
>
> I start learning mesos.
>
> How could mesos work with docker? Is there any document about this?
>
>
> Any other advice?
>
>
> Thx,
>
>
> Jared, (韦煜）
> Software developer
> Interested in open source software, big data, Linux
>

Re: Protobuf long number JSON serialisation

[Tomek Janiszewski]

Created a patch https://reviews.apache.org/r/50851/
Looking for shepherd.

pt., 5.08.2016 o 09:49 użytkownik Tomek Janiszewski 
napisał:

> I reported issue for this https://issues.apache.org/jira/browse/MESOS-5995
>
> pt., 5.08.2016 o 02:35 użytkownik Joseph Wu 
> napisał:
>
>> This is not necessarily a bug, but I think we can safely extend our
>> parsing
>> code to handle this case.
>>
>> This is the method that would need to change:
>>
>> https://github.com/apache/mesos/blob/e859d3ae8d8ff7349327b9e6a89edd6f98d2b7a1/3rdparty/stout/include/stout/protobuf.hpp#L433-L435
>>
>> On Thu, Aug 4, 2016 at 4:04 PM, Anand Mazumdar 
>> wrote:
>>
>> > Tomek,
>> >
>> > Thanks for reporting this. Looks like a bug in our JSON -> Protobuf
>> > parsing code. Mind filing a JIRA issue?
>> >
>> > -anand
>> >
>> >
>> > > On Aug 4, 2016, at 2:04 PM, Tomek Janiszewski 
>> wrote:
>> > >
>> > > Hi
>> > >
>> > > I have a problem with HTTP API. Proto2 does not specify JSON mappings
>> but
>> > > Proto3 does and it recommend to map 64bit numbers as a string.
>> > > Unfortunately Mesos does not accepts strings in places of uint64 and
>> > return
>> > > 400 Bad Request error Failed to convert JSON into Call protobuf: Not
>> > > expecting a JSON string for field 'value'.
>> > > Is this by purpose or is this a bug?
>> > >
>> > > Best
>> > > Tomek
>> >
>> >
>>
>

Re: Protobuf long number JSON serialisation

[Tomek Janiszewski]

I reported issue for this https://issues.apache.org/jira/browse/MESOS-5995

pt., 5.08.2016 o 02:35 użytkownik Joseph Wu  napisał:

> This is not necessarily a bug, but I think we can safely extend our parsing
> code to handle this case.
>
> This is the method that would need to change:
>
> https://github.com/apache/mesos/blob/e859d3ae8d8ff7349327b9e6a89edd6f98d2b7a1/3rdparty/stout/include/stout/protobuf.hpp#L433-L435
>
> On Thu, Aug 4, 2016 at 4:04 PM, Anand Mazumdar 
> wrote:
>
> > Tomek,
> >
> > Thanks for reporting this. Looks like a bug in our JSON -> Protobuf
> > parsing code. Mind filing a JIRA issue?
> >
> > -anand
> >
> >
> > > On Aug 4, 2016, at 2:04 PM, Tomek Janiszewski 
> wrote:
> > >
> > > Hi
> > >
> > > I have a problem with HTTP API. Proto2 does not specify JSON mappings
> but
> > > Proto3 does and it recommend to map 64bit numbers as a string.
> > > Unfortunately Mesos does not accepts strings in places of uint64 and
> > return
> > > 400 Bad Request error Failed to convert JSON into Call protobuf: Not
> > > expecting a JSON string for field 'value'.
> > > Is this by purpose or is this a bug?
> > >
> > > Best
> > > Tomek
> >
> >
>

Protobuf long number JSON serialisation

[Tomek Janiszewski]

Hi

I have a problem with HTTP API. Proto2 does not specify JSON mappings but
Proto3 does and it recommend to map 64bit numbers as a string.
Unfortunately Mesos does not accepts strings in places of uint64 and return
400 Bad Request error Failed to convert JSON into Call protobuf: Not
expecting a JSON string for field 'value'.
Is this by purpose or is this a bug?

Best
Tomek

Re: Patch for website

[Tomek Janiszewski]

Page need to be manually generated and published.

pon., 11.07.2016, 22:59 użytkownik Rich Bowen  napisał:

>
>
> On 2016-07-07 12:36 (-0400), "Rich Bowen" wrote:
> >
> >
> > On 2016-07-07 11:58 (-0400), Vinod Kone  wrote:
> > > Thanks Rich! The easiest is to just send a PR to our github repo:
> > > https://github.com/apache/mesos
> >
> >
> > Excellent. Will do.
> >
> >
>
> I see that the PR was merged, but the site still has the old links. Is
> there something that still needs to be done?
>

Re: Mesos Frameworks in any language

[Tomek Janiszewski]

This languages has bindings to native Mesos library that is used to
communicate with Mesos. But since we have HTTP API there is no need to link
with this lib. We should update doc and link app frameworks development
page with:
http://mesos.apache.org/documentation/latest/scheduler-http-api/
http://mesos.apache.org/documentation/latest/executor-http-api/

sob., 9.07.2016, 11:52 użytkownik Krish  napisał:

> I see from the mesos documentation here
> <
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
> >
> that
> only C++, C, Java, Scala and Python frameworks are supported. Can someone
> please explain why?
>
> My understanding of the situation was that since mesos uses
> messages/protobufs to communicate with frameworks, any protobuf-supported
> language should be a good enough fit for this task.
>
> Thanks.
>

Re: [Action Required] Stale Reviews

[Tomek Janiszewski]

How about running CI on all reviews. If patch is stale it probably can't be
applied,  CI will post bad patch and if nobody do any action on that review
we can close it.

śr., 29.06.2016, 18:26 użytkownik Joris Van Remoortere 
napisał:

> Hello developers,
>
> Over the last year we've accumulated a significant review backlog. Over the
> past month it has been floating around ~600 reviews.
>
> It would be of great help if you could look through your personal list
> (Dashboard -> Outgoing -> Open) and identify reviews that are *no longer
> relevant* or that you are *not actively working on*.
>
> Suggested actions:
> *No longer relevant: *Please discard them with a message explaining why.
> For example a link to the JIRA that was resolved already.
> *Not actively working on: *Please discard them with a note that you are not
> actively working on this, but to please involve you if someone picks it up
> in the future. A note in the JIRA referencing your discarded review would
> be much appreciated here. This way we can easily track previous effort.
>
> Remember, discarded doesn't mean deleted. It doesn't even mean this was not
> accepted. It just means we're not currently working on it. This will help
> guide reviewers and new contributors to the active set we are all working
> on.
>
> Ideally as a community we can do this organically. After some time has
> passed, we will go through and discard ones we think are categorized as
> above with a note on how to re-open them.
>
> Thanks!
> Joris
>

Re: Proposal: move content in Wiki to docs in code repo

[Tomek Janiszewski]

It's working.
Thanks

czw., 9.06.2016 o 17:06 użytkownik Vinod Kone 
napisał:

> Done. Let me know if you have edit access now.
>
> On Thu, Jun 9, 2016 at 11:01 AM, Tomek Janiszewski 
> wrote:
>
> > @Vinod I've just create the account - Tomasz Janiszewski (janisz)
> >
> > Thanks
> >
> > czw., 9.06.2016, 16:52 użytkownik Vinod Kone 
> > napisał:
> >
> >> I can give you edit access if you send me your account name (you might
> >> have to create one if you haven't already) on cwiki.apache.org
> >>
> >> On Thu, Jun 9, 2016 at 4:48 AM, Tomek Janiszewski 
> >> wrote:
> >>
> >>> @Jie could you sent me a markup from confluence editor. I have no edit
> >>> access and it will be easier to work with markup than scraping web
> page to
> >>> get data.
> >>>
> >>> czw., 9.06.2016 o 09:37 użytkownik Tomek Janiszewski <
> jani...@gmail.com>
> >>> napisał:
> >>>
> >>>> I'll post patches by the end of the week.
> >>>>
> >>>> czw., 9.06.2016 o 02:23 użytkownik Jie Yu 
> >>>> napisał:
> >>>>
> >>>>> Great! Looks like we have a consensus here!
> >>>>>
> >>>>> Tomek, you mentioned that you're interested in helping the move.
> Thank
> >>>>> you so much. Can you start with moving the following wiki pages
> first as
> >>>>> they are quite important:
> >>>>>
> >>>>> 1)
> >>>>>
> https://cwiki.apache.org/confluence/display/MESOS/Apache+Mesos+Working+Groups
> >>>>> 2)
> >>>>>
> https://cwiki.apache.org/confluence/display/MESOS/Design+docs+--+Shared+Links
> >>>>> 3)
> >>>>>
> https://cwiki.apache.org/confluence/display/MESOS/Mesos+Release+Planning
> >>>>>
> >>>>> Thanks a lot!
> >>>>> - Jie
> >>>>>
> >>>>> On Tue, Jun 7, 2016 at 5:39 AM, tommy xiao  wrote:
> >>>>>
> >>>>>> +1, good point.
> >>>>>>
> >>>>>> 2016-06-07 3:18 GMT+08:00 Vinod Kone :
> >>>>>>
> >>>>>>> Works for me. Some things we might miss from wiki would be comments
> >>>>>>> and ability to watch for updates; but I don't think many people
> use them.
> >>>>>>>
> >>>>>>> On Mon, Jun 6, 2016 at 3:15 PM, Gilbert Song <
> gilb...@mesosphere.io>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> +1.
> >>>>>>>>
> >>>>>>>> At least I personally rarely touch the wiki.
> >>>>>>>>
> >>>>>>>> Gilbert
> >>>>>>>>
> >>>>>>>> On Mon, Jun 6, 2016 at 11:51 AM, Zhou Z Xing  >
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> +1
> >>>>>>>>>
> >>>>>>>>> It's good idea to collect and gather every thing in one single
> >>>>>>>>> repo, would be easier for users to find out.
> >>>>>>>>>
> >>>>>>>>> Thanks & Best Wishes,
> >>>>>>>>>
> >>>>>>>>> Tom Xing(邢舟)
> >>>>>>>>> Emerging Technology Institute, IBM China Software Development Lab
> >>>>>>>>> --
> >>>>>>>>> IBM China Software Development Laboratory (CSDL)
> >>>>>>>>> Notes ID:Zhou Z Xing/China/IBM
> >>>>>>>>> Phone :86-10-82450442
> >>>>>>>>> e-Mail :xingz...@cn.ibm.com
> >>>>>>>>> Address :Building No.28, ZhongGuanCun Software Park, No.8 Dong
> Bei
> >>>>>>>>> Wang West Road, Haidian District, Beijing, P.R.China 100193
> >>>>>>>>> 地址 :中国北京市海淀区东北旺西路8号 中关村软件园28号楼 100193
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> [image: Inactive hide details for Jie Yu ---2016-06-06 上午
> >>>>>>>>> 11:29:42---Hi folks, I am proposing moving our content in Wiki
> (e.g., wor]Jie
> >>>>>>>>> Yu ---2016-06-06 上午 11:29:42---Hi folks, I am proposing moving
> our content
> >>>>>>>>> in Wiki (e.g., working groups, release
> >>>>>>>>>
> >>>>>>>>> From: Jie Yu 
> >>>>>>>>> To: mesos , "u...@mesos.apache.org" <
> >>>>>>>>> u...@mesos.apache.org>
> >>>>>>>>> Date: 2016-06-06 上午 11:29
> >>>>>>>>> Subject: Proposal: move content in Wiki to docs in code repo
> >>>>>>>>> --
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Hi folks,
> >>>>>>>>>
> >>>>>>>>> I am proposing moving our content in Wiki (e.g., working groups,
> >>>>>>>>> release
> >>>>>>>>> tracking, etc.) to our docs in the code repo. I personally found
> >>>>>>>>> that wiki
> >>>>>>>>> is hard to use and there's no reviewing process for changes in
> the
> >>>>>>>>> Wiki.
> >>>>>>>>> The content in Wiki historically received less attention than
> that
> >>>>>>>>> in the
> >>>>>>>>> docs.
> >>>>>>>>>
> >>>>>>>>> What do you think?
> >>>>>>>>>
> >>>>>>>>> - Jie
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Deshi Xiao
> >>>>>> Twitter: xds2000
> >>>>>> E-mail: xiaods(AT)gmail.com
> >>>>>>
> >>>>>
> >>>>>
> >>
>

Re: Proposal: move content in Wiki to docs in code repo

[Tomek Janiszewski]

@Vinod I've just create the account - Tomasz Janiszewski (janisz)

Thanks

czw., 9.06.2016, 16:52 użytkownik Vinod Kone  napisał:

> I can give you edit access if you send me your account name (you might
> have to create one if you haven't already) on cwiki.apache.org
>
> On Thu, Jun 9, 2016 at 4:48 AM, Tomek Janiszewski 
> wrote:
>
>> @Jie could you sent me a markup from confluence editor. I have no edit
>> access and it will be easier to work with markup than scraping web page to
>> get data.
>>
>> czw., 9.06.2016 o 09:37 użytkownik Tomek Janiszewski 
>> napisał:
>>
>>> I'll post patches by the end of the week.
>>>
>>> czw., 9.06.2016 o 02:23 użytkownik Jie Yu  napisał:
>>>
>>>> Great! Looks like we have a consensus here!
>>>>
>>>> Tomek, you mentioned that you're interested in helping the move. Thank
>>>> you so much. Can you start with moving the following wiki pages first as
>>>> they are quite important:
>>>>
>>>> 1)
>>>> https://cwiki.apache.org/confluence/display/MESOS/Apache+Mesos+Working+Groups
>>>> 2)
>>>> https://cwiki.apache.org/confluence/display/MESOS/Design+docs+--+Shared+Links
>>>> 3)
>>>> https://cwiki.apache.org/confluence/display/MESOS/Mesos+Release+Planning
>>>>
>>>> Thanks a lot!
>>>> - Jie
>>>>
>>>> On Tue, Jun 7, 2016 at 5:39 AM, tommy xiao  wrote:
>>>>
>>>>> +1, good point.
>>>>>
>>>>> 2016-06-07 3:18 GMT+08:00 Vinod Kone :
>>>>>
>>>>>> Works for me. Some things we might miss from wiki would be comments
>>>>>> and ability to watch for updates; but I don't think many people use them.
>>>>>>
>>>>>> On Mon, Jun 6, 2016 at 3:15 PM, Gilbert Song 
>>>>>> wrote:
>>>>>>
>>>>>>> +1.
>>>>>>>
>>>>>>> At least I personally rarely touch the wiki.
>>>>>>>
>>>>>>> Gilbert
>>>>>>>
>>>>>>> On Mon, Jun 6, 2016 at 11:51 AM, Zhou Z Xing 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> It's good idea to collect and gather every thing in one single
>>>>>>>> repo, would be easier for users to find out.
>>>>>>>>
>>>>>>>> Thanks & Best Wishes,
>>>>>>>>
>>>>>>>> Tom Xing(邢舟)
>>>>>>>> Emerging Technology Institute, IBM China Software Development Lab
>>>>>>>> --
>>>>>>>> IBM China Software Development Laboratory (CSDL)
>>>>>>>> Notes ID:Zhou Z Xing/China/IBM
>>>>>>>> Phone :86-10-82450442
>>>>>>>> e-Mail :xingz...@cn.ibm.com
>>>>>>>> Address :Building No.28, ZhongGuanCun Software Park, No.8 Dong Bei
>>>>>>>> Wang West Road, Haidian District, Beijing, P.R.China 100193
>>>>>>>> 地址 :中国北京市海淀区东北旺西路8号 中关村软件园28号楼 100193
>>>>>>>>
>>>>>>>>
>>>>>>>> [image: Inactive hide details for Jie Yu ---2016-06-06 上午
>>>>>>>> 11:29:42---Hi folks, I am proposing moving our content in Wiki (e.g., 
>>>>>>>> wor]Jie
>>>>>>>> Yu ---2016-06-06 上午 11:29:42---Hi folks, I am proposing moving our 
>>>>>>>> content
>>>>>>>> in Wiki (e.g., working groups, release
>>>>>>>>
>>>>>>>> From: Jie Yu 
>>>>>>>> To: mesos , "u...@mesos.apache.org" <
>>>>>>>> u...@mesos.apache.org>
>>>>>>>> Date: 2016-06-06 上午 11:29
>>>>>>>> Subject: Proposal: move content in Wiki to docs in code repo
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi folks,
>>>>>>>>
>>>>>>>> I am proposing moving our content in Wiki (e.g., working groups,
>>>>>>>> release
>>>>>>>> tracking, etc.) to our docs in the code repo. I personally found
>>>>>>>> that wiki
>>>>>>>> is hard to use and there's no reviewing process for changes in the
>>>>>>>> Wiki.
>>>>>>>> The content in Wiki historically received less attention than that
>>>>>>>> in the
>>>>>>>> docs.
>>>>>>>>
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>> - Jie
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Deshi Xiao
>>>>> Twitter: xds2000
>>>>> E-mail: xiaods(AT)gmail.com
>>>>>
>>>>
>>>>
>

Re: Proposal: move content in Wiki to docs in code repo

[Tomek Janiszewski]

@Jie could you sent me a markup from confluence editor. I have no edit
access and it will be easier to work with markup than scraping web page to
get data.

czw., 9.06.2016 o 09:37 użytkownik Tomek Janiszewski 
napisał:

> I'll post patches by the end of the week.
>
> czw., 9.06.2016 o 02:23 użytkownik Jie Yu  napisał:
>
>> Great! Looks like we have a consensus here!
>>
>> Tomek, you mentioned that you're interested in helping the move. Thank
>> you so much. Can you start with moving the following wiki pages first as
>> they are quite important:
>>
>> 1)
>> https://cwiki.apache.org/confluence/display/MESOS/Apache+Mesos+Working+Groups
>> 2)
>> https://cwiki.apache.org/confluence/display/MESOS/Design+docs+--+Shared+Links
>> 3)
>> https://cwiki.apache.org/confluence/display/MESOS/Mesos+Release+Planning
>>
>> Thanks a lot!
>> - Jie
>>
>> On Tue, Jun 7, 2016 at 5:39 AM, tommy xiao  wrote:
>>
>>> +1, good point.
>>>
>>> 2016-06-07 3:18 GMT+08:00 Vinod Kone :
>>>
>>>> Works for me. Some things we might miss from wiki would be comments and
>>>> ability to watch for updates; but I don't think many people use them.
>>>>
>>>> On Mon, Jun 6, 2016 at 3:15 PM, Gilbert Song 
>>>> wrote:
>>>>
>>>>> +1.
>>>>>
>>>>> At least I personally rarely touch the wiki.
>>>>>
>>>>> Gilbert
>>>>>
>>>>> On Mon, Jun 6, 2016 at 11:51 AM, Zhou Z Xing 
>>>>> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> It's good idea to collect and gather every thing in one single repo,
>>>>>> would be easier for users to find out.
>>>>>>
>>>>>> Thanks & Best Wishes,
>>>>>>
>>>>>> Tom Xing(邢舟)
>>>>>> Emerging Technology Institute, IBM China Software Development Lab
>>>>>> --
>>>>>> IBM China Software Development Laboratory (CSDL)
>>>>>> Notes ID:Zhou Z Xing/China/IBM
>>>>>> Phone :86-10-82450442
>>>>>> e-Mail :xingz...@cn.ibm.com
>>>>>> Address :Building No.28, ZhongGuanCun Software Park, No.8 Dong Bei
>>>>>> Wang West Road, Haidian District, Beijing, P.R.China 100193
>>>>>> 地址 :中国北京市海淀区东北旺西路8号 中关村软件园28号楼 100193
>>>>>>
>>>>>>
>>>>>> [image: Inactive hide details for Jie Yu ---2016-06-06 上午
>>>>>> 11:29:42---Hi folks, I am proposing moving our content in Wiki (e.g., 
>>>>>> wor]Jie
>>>>>> Yu ---2016-06-06 上午 11:29:42---Hi folks, I am proposing moving our 
>>>>>> content
>>>>>> in Wiki (e.g., working groups, release
>>>>>>
>>>>>> From: Jie Yu 
>>>>>> To: mesos , "u...@mesos.apache.org" <
>>>>>> u...@mesos.apache.org>
>>>>>> Date: 2016-06-06 上午 11:29
>>>>>> Subject: Proposal: move content in Wiki to docs in code repo
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>> I am proposing moving our content in Wiki (e.g., working groups,
>>>>>> release
>>>>>> tracking, etc.) to our docs in the code repo. I personally found that
>>>>>> wiki
>>>>>> is hard to use and there's no reviewing process for changes in the
>>>>>> Wiki.
>>>>>> The content in Wiki historically received less attention than that in
>>>>>> the
>>>>>> docs.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> - Jie
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Deshi Xiao
>>> Twitter: xds2000
>>> E-mail: xiaods(AT)gmail.com
>>>
>>
>>

Re: Proposal: move content in Wiki to docs in code repo

[Tomek Janiszewski]

I'll post patches by the end of the week.

czw., 9.06.2016 o 02:23 użytkownik Jie Yu  napisał:

> Great! Looks like we have a consensus here!
>
> Tomek, you mentioned that you're interested in helping the move. Thank you
> so much. Can you start with moving the following wiki pages first as they
> are quite important:
>
> 1)
> https://cwiki.apache.org/confluence/display/MESOS/Apache+Mesos+Working+Groups
> 2)
> https://cwiki.apache.org/confluence/display/MESOS/Design+docs+--+Shared+Links
> 3)
> https://cwiki.apache.org/confluence/display/MESOS/Mesos+Release+Planning
>
> Thanks a lot!
> - Jie
>
> On Tue, Jun 7, 2016 at 5:39 AM, tommy xiao  wrote:
>
>> +1, good point.
>>
>> 2016-06-07 3:18 GMT+08:00 Vinod Kone :
>>
>>> Works for me. Some things we might miss from wiki would be comments and
>>> ability to watch for updates; but I don't think many people use them.
>>>
>>> On Mon, Jun 6, 2016 at 3:15 PM, Gilbert Song 
>>> wrote:
>>>
 +1.

 At least I personally rarely touch the wiki.

 Gilbert

 On Mon, Jun 6, 2016 at 11:51 AM, Zhou Z Xing 
 wrote:

> +1
>
> It's good idea to collect and gather every thing in one single repo,
> would be easier for users to find out.
>
> Thanks & Best Wishes,
>
> Tom Xing(邢舟)
> Emerging Technology Institute, IBM China Software Development Lab
> --
> IBM China Software Development Laboratory (CSDL)
> Notes ID:Zhou Z Xing/China/IBM
> Phone :86-10-82450442
> e-Mail :xingz...@cn.ibm.com
> Address :Building No.28, ZhongGuanCun Software Park, No.8 Dong Bei
> Wang West Road, Haidian District, Beijing, P.R.China 100193
> 地址 :中国北京市海淀区东北旺西路8号 中关村软件园28号楼 100193
>
>
> [image: Inactive hide details for Jie Yu ---2016-06-06 上午
> 11:29:42---Hi folks, I am proposing moving our content in Wiki (e.g., 
> wor]Jie
> Yu ---2016-06-06 上午 11:29:42---Hi folks, I am proposing moving our content
> in Wiki (e.g., working groups, release
>
> From: Jie Yu 
> To: mesos , "u...@mesos.apache.org" <
> u...@mesos.apache.org>
> Date: 2016-06-06 上午 11:29
> Subject: Proposal: move content in Wiki to docs in code repo
> --
>
>
>
> Hi folks,
>
> I am proposing moving our content in Wiki (e.g., working groups,
> release
> tracking, etc.) to our docs in the code repo. I personally found that
> wiki
> is hard to use and there's no reviewing process for changes in the
> Wiki.
> The content in Wiki historically received less attention than that in
> the
> docs.
>
> What do you think?
>
> - Jie
>
>
>
>

>>>
>>
>>
>> --
>> Deshi Xiao
>> Twitter: xds2000
>> E-mail: xiaods(AT)gmail.com
>>
>
>

Re: [C++11] Please use `nullptr`!

[Tomek Janiszewski]

No, we left it untouched.
I prepared simple check that could be reviewed here
https://reviews.apache.org/r/48320/
It's far from perfect, but works in most cases. The real solution will be
using clang-modernize.

Best
Tomek

wt., 7.06.2016 o 01:15 użytkownik Benjamin Mahler 
napisał:

> Thanks Tomasz!
>
> Does the style checker now catch NULL introductions?
>
> On Mon, Jun 6, 2016 at 2:12 PM, Michael Park  wrote:
>
> > Hello,
> >
> > Tomasz Janiszewski kindly started the initiative on the migration to
> > `nullptr`, and we have closed MESOS-3243
> > .
> >
> > The existing instances of `NULL` have been replaced with `nullptr`, and
> any
> > new or remaining instances of `NULL` are bugs. Please let me know if we
> > missed any, or if there are any that happen to sneak through during this
> > transition period.
> >
> > Thanks,
> >
> > MPark
> >
>

Re: Proposal: move content in Wiki to docs in code repo

[Tomek Janiszewski]

+1
For a long time I didn't knew that wiki exists. It's hidden from a new
users and search engines - I remember only one place where it's linked in
docs.
I can help with move.

pon., 6.06.2016, 20:29 użytkownik Jie Yu  napisał:

> Hi folks,
>
> I am proposing moving our content in Wiki (e.g., working groups, release
> tracking, etc.) to our docs in the code repo. I personally found that wiki
> is hard to use and there's no reviewing process for changes in the Wiki.
> The content in Wiki historically received less attention than that in the
> docs.
>
> What do you think?
>
> - Jie
>

Re: Completed executors presented as alive

[Tomek Janiszewski]

Too late. Sandbox was collected by GC.

sob., 4.06.2016 o 12:45 użytkownik haosdent  napisał:

> Usually executor would terminate itself if it reap the task status is
> killed or finished.
> Otherwise the reap callback have not yet registered not our executor has
> bug when
> reap task status. Could you find something in the executor stdout/stderr ?
>
> On Sat, Jun 4, 2016 at 6:08 PM, Tomek Janiszewski 
> wrote:
>
> > Thanks. I just manually find that executor pid and killed it. Any idea
> why
> > it was still running without tasks?
> >
> > sob., 4.06.2016, 05:35 użytkownik haosdent  napisał:
> >
> > > > 13:33:39.031054  [slave.cpp:2643] Got registration for executor
> > > 'service.a3b609b8-27ec-11e6-8044-02c89eb9127e' of framework
> > > f65b163c-0faf-441f-ac14-91739fa4394c- from executor(1)@
> > > 10.55.97.170:60083
> > >
> > > Yes, according to your log, your executor is still running. If your
> > > executor is http_command_executor,
> > > you could use
> > >
> > >
> >
> https://github.com/apache/mesos/blob/master/docs/executor-http-api.md#shutdown
> > > to shutdown it.
> > > If it is other type executor, seems don't have a api to shutdown
> executor
> > > as I know. Not sure whether kill the executor in
> > > Agent could resolve your problem or not.
> > >
> > > On Fri, Jun 3, 2016 at 4:33 PM, Tomek Janiszewski 
> > > wrote:
> > >
> > > > Here is truncated response from slave(1)/state
> > > >
> > > > {
> > > > "attributes": {...},
> > > > "completed_frameworks": [],
> > > > "flags": {...},
> > > > "frameworks": [
> > > > {
> > > > "checkpoint": true,
> > > > "completed_executors": [...],
> > > > "executors": [
> > > >   {
> > > >   "queued_tasks": [],
> > > >   "tasks": [],
> > > >   "completed_tasks": [
> > > >   {
> > > >   "discovery": {...},
> > > >   "executor_id": "",
> > > >   "framework_id":
> > > > "f65b163c-0faf-441f-ac14-91739fa4394c-",
> > > >   "id":
> > > > "service.a3b609b8-27ec-11e6-8044-02c89eb9127e",
> > > >   "labels": [...],
> > > >   "name": "service",
> > > >   "resources": {...},
> > > >   "slave_id":
> > > > "ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13",
> > > >   "state": "TASK_KILLED",
> > > >   "statuses": []
> > > >   }
> > > >   ],
> > > >   "container":
> "ead42e63-ac92-4ad0-a99c-4af9c3fa5e31",
> > > >   "directory": "...",
> > > >   "id":
> "service.a3b609b8-27ec-11e6-8044-02c89eb9127e",
> > > >   "name": "Command Executor (Task:
> > > > service.a3b609b8-27ec-11e6-8044-02c89eb9127e) (Command: sh -c 'cd
> > > > service...')",
> > > >   "resources": {...},
> > > >   "source":
> > > "service.a3b609b8-27ec-11e6-8044-02c89eb9127e"
> > > >
> > > >   },
> > > >   ...
> > > > ],
> > > > }
> > > > ],
> > > > "git_sha": "961edbd82e691a619a4c171a7aadc9c32957fa73",
> > > > "git_tag": "0.28.0",
> > > > "version": "0.28.0",
> > > > ...
> > > > }
> > > >
> > > > Here is the log for this container:
> > > >
> > > > > 13:33:19.479182  [slave.cpp:1361] Got assigned task
> > > > service.a3b609b8-27ec-11e6-8044-02c89eb9127e for framework
> > > > f65b163c-0faf-441f

Re: Completed executors presented as alive

[Tomek Janiszewski]

Thanks. I just manually find that executor pid and killed it. Any idea why
it was still running without tasks?

sob., 4.06.2016, 05:35 użytkownik haosdent  napisał:

> > 13:33:39.031054  [slave.cpp:2643] Got registration for executor
> 'service.a3b609b8-27ec-11e6-8044-02c89eb9127e' of framework
> f65b163c-0faf-441f-ac14-91739fa4394c- from executor(1)@
> 10.55.97.170:60083
>
> Yes, according to your log, your executor is still running. If your
> executor is http_command_executor,
> you could use
>
> https://github.com/apache/mesos/blob/master/docs/executor-http-api.md#shutdown
> to shutdown it.
> If it is other type executor, seems don't have a api to shutdown executor
> as I know. Not sure whether kill the executor in
> Agent could resolve your problem or not.
>
> On Fri, Jun 3, 2016 at 4:33 PM, Tomek Janiszewski 
> wrote:
>
> > Here is truncated response from slave(1)/state
> >
> > {
> > "attributes": {...},
> > "completed_frameworks": [],
> > "flags": {...},
> > "frameworks": [
> > {
> > "checkpoint": true,
> > "completed_executors": [...],
> > "executors": [
> >   {
> >   "queued_tasks": [],
> >   "tasks": [],
> >   "completed_tasks": [
> >   {
> >   "discovery": {...},
> >   "executor_id": "",
> >   "framework_id":
> > "f65b163c-0faf-441f-ac14-91739fa4394c-",
> >   "id":
> > "service.a3b609b8-27ec-11e6-8044-02c89eb9127e",
> >   "labels": [...],
> >   "name": "service",
> >   "resources": {...},
> >   "slave_id":
> > "ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13",
> >   "state": "TASK_KILLED",
> >   "statuses": []
> >   }
> >   ],
> >   "container": "ead42e63-ac92-4ad0-a99c-4af9c3fa5e31",
> >   "directory": "...",
> >   "id": "service.a3b609b8-27ec-11e6-8044-02c89eb9127e",
> >   "name": "Command Executor (Task:
> > service.a3b609b8-27ec-11e6-8044-02c89eb9127e) (Command: sh -c 'cd
> > service...')",
> >   "resources": {...},
> >   "source":
> "service.a3b609b8-27ec-11e6-8044-02c89eb9127e"
> >
> >   },
> >   ...
> > ],
> > }
> > ],
> > "git_sha": "961edbd82e691a619a4c171a7aadc9c32957fa73",
> > "git_tag": "0.28.0",
> > "version": "0.28.0",
> > ...
> > }
> >
> > Here is the log for this container:
> >
> > > 13:33:19.479182  [slave.cpp:1361] Got assigned task
> > service.a3b609b8-27ec-11e6-8044-02c89eb9127e for framework
> > f65b163c-0faf-441f-ac14-91739fa4394c-
> > > 13:33:19.482566  [slave.cpp:1480] Launching task
> > service.a3b609b8-27ec-11e6-8044-02c89eb9127e for framework
> > f65b163c-0faf-441f-ac14-91739fa4394c-
> > > 13:33:19.483921  [paths.cpp:528] Trying to chown
> >
> >
> '/tmp/mesos/slaves/ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13/frameworks/f65b163c-0faf-441f-ac14-91739fa4394c-/executors/service.a3b609b8-27ec-11e6-8044-02c89eb9127e/runs/ead42e63-ac92-4ad0-a99c-4af9c3fa5e31'
> > to user 'mesosuser'
> > > 13:33:19.504173  [slave.cpp:5367] Launching executor
> > service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
> > f65b163c-0faf-441f-ac14-91739fa4394c- with resources cpus(*):0.1;
> > mem(*):32 in work directory
> >
> >
> '/tmp/mesos/slaves/ef232fd9-5114-4d8f-adc3-1669c1e6fdc5-S13/frameworks/f65b163c-0faf-441f-ac14-91739fa4394c-/executors/service.a3b609b8-27ec-11e6-8044-02c89eb9127e/runs/ead42e63-ac92-4ad0-a99c-4af9c3fa5e31'
> > > 13:33:19.505537  [containerizer.cpp:666] Starting container
> > 'ead42e63-ac92-4ad0-a99c-4af9c3fa5e31' for executor
> > 'service.a3b609b8-27ec-11e6-8044-02c89eb9127e' of frame

Re: Completed executors presented as alive

[Tomek Janiszewski]

02c89eb9127e of framework
f65b163c-0faf-441f-ac14-9173
9fa4394c-
> 13:33:35.783860  [status_update_manager.cpp:824] Checkpointing UPDATE for
status update TASK_KILLED (UUID: eba64915-7df2-483d-8982-a9a46a48a81b) for
task service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
f65b163c-0faf-441f-ac14-91739fa4394c-
> 13:33:35.788767  [slave.cpp:3400] Forwarding the update TASK_KILLED
(UUID: eba64915-7df2-483d-8982-a9a46a48a81b) for task
service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
f65b163c-0faf-441f-ac14-91739fa4394c- to master@10.82.24.138:5050
> 13:33:35.917932  [status_update_manager.cpp:392] Received status update
acknowledgement (UUID: eba64915-7df2-483d-8982-a9a46a48a81b) for task
service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
f65b163c-0faf-441f-ac14-91739fa4394c-
> 13:33:35.918143  [status_update_manager.cpp:824] Checkpointing ACK for
status update TASK_KILLED (UUID: eba64915-7df2-483d-8982-a9a46a48a81b) for
task service.a3b609b8-27ec-11e6-8044-02c89eb9127e of framework
f65b163c-0faf-441f-ac14-91739fa4394c-
...
> 13:33:39.031054  [slave.cpp:2643] Got registration for executor
'service.a3b609b8-27ec-11e6-8044-02c89eb9127e' of framework
f65b163c-0faf-441f-ac14-91739fa4394c- from executor(1)@
10.55.97.170:60083


Visible container is no longer running but it appears as running. What
should I do with it?

Thanks
Tomek


czw., 2.06.2016 o 15:55 użytkownik Tomek Janiszewski 
napisał:

> Yes. I see dead executor in executors. It's tasks and queued_tasks are
> empty but there is one task in completed_tasks. frameworks.completed_executors
> are filled with other executors.
>
> czw., 2.06.2016 o 15:39 użytkownik haosdent  napisał:
>
>> Hi, @janiszt Seems the completed executors only exists
>> in completed_frameworks.completed_executors
>> or frameworks.completed_executors in my side.
>>
>> In your side, does completed_executors exists in any other fields?
>>
>> On Thu, Jun 2, 2016 at 5:39 PM, Tomek Janiszewski 
>> wrote:
>>
>> > Hi
>> >
>> > I'm running Mesos 0.28.0. Mesos slave(1)/state endpoint returns some
>> > completed executors not in frameworks.completed_executors but in
>> > frameworks.
>> > executors.
>> > Is it normal behavior? How to force Mesos to move completed
>> > executors into frameworks.executors?
>> >
>> > Thanks
>> > Tomek
>> >
>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>

Re: Completed executors presented as alive

[Tomek Janiszewski]

Yes. I see dead executor in executors. It's tasks and queued_tasks are
empty but there is one task in completed_tasks. frameworks.completed_executors
are filled with other executors.

czw., 2.06.2016 o 15:39 użytkownik haosdent  napisał:

> Hi, @janiszt Seems the completed executors only exists
> in completed_frameworks.completed_executors
> or frameworks.completed_executors in my side.
>
> In your side, does completed_executors exists in any other fields?
>
> On Thu, Jun 2, 2016 at 5:39 PM, Tomek Janiszewski 
> wrote:
>
> > Hi
> >
> > I'm running Mesos 0.28.0. Mesos slave(1)/state endpoint returns some
> > completed executors not in frameworks.completed_executors but in
> > frameworks.
> > executors.
> > Is it normal behavior? How to force Mesos to move completed
> > executors into frameworks.executors?
> >
> > Thanks
> > Tomek
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Completed executors presented as alive

[Tomek Janiszewski]

Hi

I'm running Mesos 0.28.0. Mesos slave(1)/state endpoint returns some
completed executors not in frameworks.completed_executors but in frameworks.
executors.
Is it normal behavior? How to force Mesos to move completed
executors into frameworks.executors?

Thanks
Tomek

[WEBSITE] Readme update

[Tomek Janiszewski]

Hi

I think website readme 
is out of date.
1. It doesn't mention mesos-website-container

2. support/generate-help-site.py does not exists
Am I right? How to generate full site (with documentation and getting
started section)?

Thanks
Tomek

Re: [WEBSITE] Website refresh

[Tomek Janiszewski]

JIRA: https://issues.apache.org/jira/browse/MESOS-5402
PR: https://reviews.apache.org/r/47499/

wt., 17.05.2016 o 22:30 użytkownik Timothy Anderegg <
timothy.ander...@gmail.com> napisał:

> Happy to help review the change
>
> On Tue, May 17, 2016, 4:26 PM Vinod Kone  wrote:
>
> > Great. Can you file tickets for these and submit patches? I can help
> commit
> > them. Would be great if people with front-end experience can review the
> > changes though.
> >
> > On Tue, May 17, 2016 at 1:23 PM, Tomek Janiszewski 
> > wrote:
> >
> > > Currently only issue I spotted on mobile is text that is not wrapped. I
> > > checked in devtools and adding *@media only screen and
> (max-width:985px)*
> > >  above .container
> > > <
> > >
> >
> https://github.com/apache/mesos/blob/4d2b1b793e07a9c90b984ca330a3d7bc9e1404cc/site/source/assets/css/main.css#L28
> > > >
> > > solve
> > > this but add another issues
> > > 1. Missing left padding in jumbotron – minor issue but it really
> doesn't
> > > look good
> > > 2. links in navbar hides on small screens due to hardcoded height
> > > <
> > >
> >
> https://github.com/apache/mesos/blob/4d2b1b793e07a9c90b984ca330a3d7bc9e1404cc/site/source/assets/css/main.css#L103
> > > >
> > >
> > > 3. Tables still need scrolling but IMO it's OK
> > > There could be other issues I haven't noticed, but on the first sight
> > > making site mobile friendlier doesn't look hard.
> > >
> > > wt., 17.05.2016 o 21:19 użytkownik Vinod Kone 
> > > napisał:
> > >
> > > > On Tue, May 17, 2016 at 10:18 AM, Tomek Janiszewski <
> jani...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > In short term we could make it mobile friendly
> > > >
> > > >
> > > > Can this be done easily? What needs to change?
> > > >
> > >
> >
>

Re: [WEBSITE] Website refresh

[Tomek Janiszewski]

Currently only issue I spotted on mobile is text that is not wrapped. I
checked in devtools and adding *@media only screen and (max-width:985px)*
 above .container
<https://github.com/apache/mesos/blob/4d2b1b793e07a9c90b984ca330a3d7bc9e1404cc/site/source/assets/css/main.css#L28>
solve
this but add another issues
1. Missing left padding in jumbotron – minor issue but it really doesn't
look good
2. links in navbar hides on small screens due to hardcoded height
<https://github.com/apache/mesos/blob/4d2b1b793e07a9c90b984ca330a3d7bc9e1404cc/site/source/assets/css/main.css#L103>

3. Tables still need scrolling but IMO it's OK
There could be other issues I haven't noticed, but on the first sight
making site mobile friendlier doesn't look hard.

wt., 17.05.2016 o 21:19 użytkownik Vinod Kone 
napisał:

> On Tue, May 17, 2016 at 10:18 AM, Tomek Janiszewski 
> wrote:
>
> > In short term we could make it mobile friendly
>
>
> Can this be done easily? What needs to change?
>

Re: [WEBSITE] Website refresh

[Tomek Janiszewski]

In short term we could make it mobile friendly. Also first page could be
less ascetic more like http://concord.io/

wt., 17.05.2016, 18:55 użytkownik haosdent  napisał:

> > Is there anything else we could do in the short-term?
>
> Add some case studies? May just a link to MesosConf video in youtube or
> some organization/company blogs. Compared to a simple "Powered By Mesos"
> list, they may more detail and convincing.
>
> On Wed, May 18, 2016 at 12:48 AM, Vinod Kone  wrote:
>
> > Hi,
> >
> > What's the minimum we could do to spruce up the website for MesosCon?
> >
> > Given the time, I think improving the home page would be a good start? I
> > had some discussions with Mesosphere's design team and they kindly agreed
> > to help out here. Once they have the design doc for the home page update
> > ready, I will share it with the community and we can review it.
> >
> > Is there anything else we could do in the short-term? Content
> > re-organization seems like the most beneficial thing we could do but that
> > might take a lot more time.
> >
> > Thanks,
> > Vinod
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: mesos website workgroup

[Tomek Janiszewski]

Count me in.

Tomek

wt., 17.05.2016, 07:49 użytkownik Abhishek Dasgupta <
a10gu...@linux.vnet.ibm.com> napisał:

> I would be very much interested. I have some front-end experience as
> well. Please, include me too.
>
> On মঙ্গলবার 17 মে 2016 02:32 পূর্বাহ্ণ, Vinod Kone wrote:
> > Hi guys,
> >
> > Mesos website needs some love. It hasn't seen major changes for a while
> now
> > and there is no real maintainer for it.
> >
> > I'm proposing we start a work group for the folks who are interested in
> > contributing to the website. Especially folks who have interest and
> > experience in frontend development or at least have access to folks with
> > that experience (maybe colleagues at your company).
> >
> > Since we are gearing up for a 1.0 release, it would be nice to do a
> website
> > refresh.
> >
> > Please reply to this email if you are interested.
> >
> > Thanks,
> > Vinod
> >
>
>

Re: Running Mesos agent on ARM (Raspberry Pi)?

[Tomek Janiszewski]

Cool. Did you hit any trubles with that setup?

pt., 13.05.2016, 03:13 użytkownik Sharma Podila 
napisał:

> We have Mesos agents running on Pi3's taking tasks from master running on
> a Linux laptop.
>
> https://twitter.com/aspyker/status/730924571440779264
>
> More info to follow.
>
> Thanks for all the pointers.
>
>
> On Fri, Apr 29, 2016 at 1:09 PM, Sharma Podila 
> wrote:
>
>> Fyi- Things are progressing, we have a build on Pi. The agent was able to
>> come up and register with a master running on a regular Linux server.
>>
>> https://twitter.com/aspyker/status/725923864031559681
>>
>> The master has problem running with this build on the Pi, but, that isn't
>> a goal for us. We are running Mesos 0.24.1 for now. We'll document our
>> build steps, etc. here soon.
>>
>>
>>
>> On Mon, Apr 25, 2016 at 10:21 AM, Sharma Podila 
>> wrote:
>>
>>> This is for an internal hackday project, not for a production setup.
>>>
>>>
>>> On Mon, Apr 25, 2016 at 1:05 AM, Aaron Carey  wrote:
>>>
 Out of curiosity... is this for fun or production workloads? I'd be
 curious to hear about raspis being used in production!

 --

 Aaron Carey
 Production Engineer - Cloud Pipeline
 Industrial Light & Magic
 London
 020 3751 9150

 --
 *From:* Sharma Podila [spod...@netflix.com]
 *Sent:* 22 April 2016 17:53
 *To:* u...@mesos.apache.org; dev
 *Subject:* Running Mesos agent on ARM (Raspberry Pi)?

 We are working on a hack to run Mesos agents on Raspberry Pi and are
 wondering if anyone here has done that before. From the Google search
 results we looked at so far, it seems like it has been compiled, but we
 haven't seen an indication that anyone has run it and launched tasks on
 them. And does it sound right that it might take 4 hours or so to compile?

 We are looking to run just the agents. The master will be on a regular
 Ubuntu laptop or a server.

 Appreciate any pointers.



>>>
>>
>

Looking for Shepherd for MESOS-2201

[Tomek Janiszewski]

Hi

Can anyone help shepherd MESOS-2201 – Fixed replica log restore tests.
This issue is first step to upgrade leveldb.

https://issues.apache.org/jira/browse/MESOS-2201
https://reviews.apache.org/r/47161/

Thanks
Tomek

Re: Running Mesos agent on ARM (Raspberry Pi)?

[Tomek Janiszewski]

Current master version should build on Pi3 but there still could be a
problem with leveldb.

wt., 3.05.2016 o 16:40 użytkownik Andreas Fritzler <
andreas.fritz...@gmail.com> napisał:

> Did anybody try to build and run Mesos on a Raspberry Pi3? Will that work
> out of the box (due to the 64bit ARM)?
>
> On Sat, Apr 30, 2016 at 5:54 AM, haosdent  wrote:
>
>> >The master has problem running with this build on the Pi
>> You need launch master with `--registry=in_memory`, replicated_log with
>> leveldb has problem in Mesos master.
>>
>> On Sat, Apr 30, 2016 at 4:09 AM, Sharma Podila 
>> wrote:
>>
>> > Fyi- Things are progressing, we have a build on Pi. The agent was able
>> to
>> > come up and register with a master running on a regular Linux server.
>> >
>> > https://twitter.com/aspyker/status/725923864031559681
>> >
>> > The master has problem running with this build on the Pi, but, that
>> isn't
>> > a goal for us. We are running Mesos 0.24.1 for now. We'll document our
>> > build steps, etc. here soon.
>> >
>> >
>> >
>> > On Mon, Apr 25, 2016 at 10:21 AM, Sharma Podila 
>> > wrote:
>> >
>> >> This is for an internal hackday project, not for a production setup.
>> >>
>> >>
>> >> On Mon, Apr 25, 2016 at 1:05 AM, Aaron Carey  wrote:
>> >>
>> >>> Out of curiosity... is this for fun or production workloads? I'd be
>> >>> curious to hear about raspis being used in production!
>> >>>
>> >>> --
>> >>>
>> >>> Aaron Carey
>> >>> Production Engineer - Cloud Pipeline
>> >>> Industrial Light & Magic
>> >>> London
>> >>> 020 3751 9150
>> >>>
>> >>> --
>> >>> *From:* Sharma Podila [spod...@netflix.com]
>> >>> *Sent:* 22 April 2016 17:53
>> >>> *To:* u...@mesos.apache.org; dev
>> >>> *Subject:* Running Mesos agent on ARM (Raspberry Pi)?
>> >>>
>> >>> We are working on a hack to run Mesos agents on Raspberry Pi and are
>> >>> wondering if anyone here has done that before. From the Google search
>> >>> results we looked at so far, it seems like it has been compiled, but
>> we
>> >>> haven't seen an indication that anyone has run it and launched tasks
>> on
>> >>> them. And does it sound right that it might take 4 hours or so to
>> compile?
>> >>>
>> >>> We are looking to run just the agents. The master will be on a regular
>> >>> Ubuntu laptop or a server.
>> >>>
>> >>> Appreciate any pointers.
>> >>>
>> >>>
>> >>>
>> >>
>> >
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>
>

Re: Looking for Shepherd for MESOS-5263

[Tomek Janiszewski]

Hi

I prepared cleanup https://reviews.apache.org/r/46730/
@Haosdent can you check it?

Best
Tomek

śr., 27.04.2016 o 04:03 użytkownik haosdent  napisał:

> Hi, @bmahler, thank you so much for review it! As the email I sent
> to @idownes and @chenzhiwei, we could drop that safely by adding
>
> ```
> #include 
> ```
>
> from @RobinDong's patch.
>
> Because this header file comes from kernel headers and it include machine
> specific syscall numbers no matter which CPU architecture used.
>
> On the other hand, we can not use
>
> ```
> #include 
> #include 
> ```
>
> as the source of the syscall numbers because these header files come from
> glibc.
>
> ```
> $ rpm -qf /usr/include/sys/syscall.h
> glibc-headers-2.12-1.149.el6_6.5.x86_64
> $ rpm -qf /usr/include/unistd.h
> glibc-headers-2.12-1.149.el6_6.5.x86_64
> ```
>
> If use them, would fall into the problem @idownes mentioned in
> `linux/ns.hpp` (Old glibc library and new kernel)
>
> ```
> #ifdef SYS_setns
>   int ret = ::syscall(SYS_setns, fd.get(), nstype.get());
> #elif __x86_64__
>   // A workaround for those hosts that have an old glibc (older than
>   // 2.14) but have a new kernel. The magic number '308' here is the
>   // syscall number for 'setns' on x86_64 architecture.
>   int ret = ::syscall(308, fd.get(), nstype.get());
> #else
> #error "setns is not available"
> #endif
> ```
>
> I verify `#include ` works on CentOS 6.5, CentOS 7.2 Ubuntu
> 14.04 with X86 and Debian jessie with ARM. In code level, I verify it works
> on all architectures I know [
> http://lxr.free-electrons.com/ident?v=3.8;i=__NR_pivot_root] .
>
> @BingLi would like to port Mesos works on System Z, and he blocked by
> `__NR_pivot_root ` (https://issues.apache.org/jira/browse/MESOS-5242) as
> well. As he commented in ticket, `#include ` could solve
> the problem as well.
>
>
> Appendix[The verify program]:
>
> ```
> #include 
> #include 
>
> int main(int argc, char const *argv[])
> {
>   std::cout << __NR_pivot_root << std::endl;
>   return 0;
> }
> ```
>
>
> On Wed, Apr 27, 2016 at 3:24 AM, Benjamin Mahler 
> wrote:
>
> > Looks like Vinod shipped MESOS-5121. I just shipped MESOS-5263 following
> > the same approach.
> >
> > Haosdent mentioned some cleanups are possible here so please keep us
> > posted if the cleanups are available!
> >
> > On Sun, Apr 24, 2016 at 1:34 PM, Tomek Janiszewski 
> > wrote:
> >
> >> Hi,
> >>
> >> Can anyone shepherd https://issues.apache.org/jira/browse/MESOS-5263?
> >> It's similar to https://issues.apache.org/jira/browse/MESOS-5121 and
> >> could
> >> be resolved in the same manner or it could be done in a way that'll
> >> support
> >> other platforms as well.
> >>
> >> Thanks
> >> Tomek
> >>
> >
> >
>
>
> --
> Best Regards,
> Haosdent Huang
>

Looking for Shepherd for MESOS-5263

[Tomek Janiszewski]

Hi,

Can anyone shepherd https://issues.apache.org/jira/browse/MESOS-5263?
It's similar to https://issues.apache.org/jira/browse/MESOS-5121 and could
be resolved in the same manner or it could be done in a way that'll support
other platforms as well.

Thanks
Tomek

Re: Running Mesos agent on ARM (Raspberry Pi)?

[Tomek Janiszewski]

@haosdent Here you are https://reviews.apache.org/r/46610/ I hope I'll find
more time to hack on RPI next week.

niedz., 24.04.2016 o 12:04 użytkownik haosdent  napisał:

> Tomek's Mesos on ARM seems out of date, and it is a bit painful to set up
> a Raspberry Pi development environment in x86 machine.
>
> So I create a docker image `haosdent/raspberry` to simple this and
> document how to patch, compile and running mesos on the Raspberry Pi in
> this [post](http://blog.haosdent.me/2016/04/24/mesos-on-arm/). Hope it is
> helpful for you if you are seeking to run Mesos on ARM.
>
> In additional, thanks to @zhiwei and @vinodkone's work recently. Bundle
> zookeeper package have already upgraded to 3.4.8 which could pass compile
> on ARM. The only change to make mesos pass compile on ARM is to patch
>  `pivot_root` in fs.cpp. @Tomek would you like to modify it according to my
> suggestions on your github and post it in review board
> https://reviews.apache.org/groups/mesos/ to further review? I think it is
> necessary if we want to make Mesos run on ARM perfectly.
>
> On Sat, Apr 23, 2016 at 9:42 AM, Sharma Podila 
> wrote:
>
>> Appreciate all the pointers so far. We'll certainly share what we end up
>> with in a few weeks.
>>
>>
>> On Fri, Apr 22, 2016 at 5:49 PM, tommy xiao  wrote:
>>
>>> the alternative way, use Docker on rpi to containerised the mesos master
>>> and slave, it also cool things.
>>>
>>> 2016-04-23 1:38 GMT+08:00 Dario Rexin :
>>>
>>>> Hi Sharma,
>>>>
>>>> I played around with Mesos on RPi a while back and have been able to
>>>> compile and run it with 2 little patches.
>>>>
>>>> 1) Depending on the ZK version, it may be necessary to patch a function
>>>> that uses inline ASM to use the resp. compiler intrinsics (I don’t remember
>>>> where exactly in zk it was, but the compile error should tell you)
>>>>
>>>> 2) There is string formatting code somewhere that compiles, but is not
>>>> architecture independent, i.e. behaves different on 32 and 64 bit. IIRC the
>>>> fix was to change %lu to %llu or something close to that. The stack trace
>>>> when Mesos crashes should tell you. If you’re lucky enough to have an RPi3,
>>>> this may not be necessary.
>>>>
>>>> Also, if you compile on the RPi make sure to create a swap file of
>>>> >=512MB. The build process will use lots of memory. I have not been able to
>>>> compile on multiple cores, because the memory usage was just too high.
>>>>
>>>> I hope this helps.
>>>>
>>>> On Apr 22, 2016, at 10:23 AM, Tomek Janiszewski 
>>>> wrote:
>>>>
>>>> As @haosdent mentioned with Kevin we tried to run it on ARM. AFAIR
>>>> there was a problem only with master, agents runs smoothly (or pretend to).
>>>> To run it on RPi you need to compile it for ARM. Easy but long solution is
>>>> to compile it on rpi. Quick but a little bit harder  cross compile it on
>>>> "normal" machine and upload to device.
>>>>
>>>>
>>>> http://likemagicappears.com/projects/raspberry-pi-cluster/mesos-on-raspbian/
>>>>
>>>> pt., 22 kwi 2016, 19:02 użytkownik haosdent 
>>>> napisał:
>>>>
>>>>> Tomek have a gsoc proposal to make Mesos build on ARM
>>>>> https://docs.google.com/document/d/1zbms2jQfExuIm6g-adqaXjFpPif6OsqJ84KAgMrOjHQ/edit
>>>>> I think you could take a look at this code in github
>>>>> https://github.com/lyda/mesos-on-arm
>>>>>
>>>>> On Sat, Apr 23, 2016 at 12:53 AM, Sharma Podila 
>>>>> wrote:
>>>>>
>>>>>> We are working on a hack to run Mesos agents on Raspberry Pi and are
>>>>>> wondering if anyone here has done that before. From the Google search
>>>>>> results we looked at so far, it seems like it has been compiled, but we
>>>>>> haven't seen an indication that anyone has run it and launched tasks on
>>>>>> them. And does it sound right that it might take 4 hours or so to 
>>>>>> compile?
>>>>>>
>>>>>> We are looking to run just the agents. The master will be on a
>>>>>> regular Ubuntu laptop or a server.
>>>>>>
>>>>>> Appreciate any pointers.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Regards,
>>>>> Haosdent Huang
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Deshi Xiao
>>> Twitter: xds2000
>>> E-mail: xiaods(AT)gmail.com
>>>
>>
>>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Running Mesos agent on ARM (Raspberry Pi)?

[Tomek Janiszewski]

As @haosdent mentioned with Kevin we tried to run it on ARM. AFAIR there
was a problem only with master, agents runs smoothly (or pretend to). To
run it on RPi you need to compile it for ARM. Easy but long solution is to
compile it on rpi. Quick but a little bit harder  cross compile it on
"normal" machine and upload to device.

http://likemagicappears.com/projects/raspberry-pi-cluster/mesos-on-raspbian/

pt., 22 kwi 2016, 19:02 użytkownik haosdent  napisał:

> Tomek have a gsoc proposal to make Mesos build on ARM
> https://docs.google.com/document/d/1zbms2jQfExuIm6g-adqaXjFpPif6OsqJ84KAgMrOjHQ/edit
> I think you could take a look at this code in github
> https://github.com/lyda/mesos-on-arm
>
> On Sat, Apr 23, 2016 at 12:53 AM, Sharma Podila 
> wrote:
>
>> We are working on a hack to run Mesos agents on Raspberry Pi and are
>> wondering if anyone here has done that before. From the Google search
>> results we looked at so far, it seems like it has been compiled, but we
>> haven't seen an indication that anyone has run it and launched tasks on
>> them. And does it sound right that it might take 4 hours or so to compile?
>>
>> We are looking to run just the agents. The master will be on a regular
>> Ubuntu laptop or a server.
>>
>> Appreciate any pointers.
>>
>>
>>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Vote on #MesosCon proposals, deadline Friday March 25

[Tomek Janiszewski]

@David Do you have results?

pon., 21.03.2016 o 14:39 użytkownik David Greenberg 
napisał:

> No, sorry--we'll collect the votes on Friday.
>
> Thanks,
> David
>
> On Sun, Mar 20, 2016 at 9:01 PM Darren Haas  wrote:
>
>> Hi David,
>>
>> We could always start the ranking using shuf. :) Is it possible to show
>> the current votes during the ranking?
>>
>> Thanks,
>> Darren
>>
>>
>>
>>
>> Sent from my iPhone
>> On Mar 19, 2016, at 4:45 PM, David Greenberg 
>> wrote:
>>
>> Hi Jay,
>>
>> Thanks for your feedback! The reason we're asking for you to rank the
>> topics is that this will allow us to better understand everyone's relative
>> preferences--next, we'll use standard voting algorithms to determine the
>> schedule, to ensure most people get as many talks they want as possible. We
>> hope you enjoy the program we come up with :)
>>
>> Thanks,
>> David
>>
>> On Sat, Mar 19, 2016 at 12:39 AM Jay JN Guo 
>> wrote:
>>
>>> Hi,
>>>
>>> Thank you for this good work and I'm already looking forward to this
>>> MesosCon.
>>>
>>> Although one minor suggestion here, Accept/Reject on a scale of 10 is a
>>> bit intimidating. Personally, I only have three feeling toward a topic:
>>> will go/maybe/not interested, whereas quantifying these feeling into a
>>> scale of 10 for 154 topics is just too much. Maybe we could simplify the
>>> form in the future. We could take OpenStack summit voting form as an
>>> example.
>>>
>>> Cheers,
>>> /J
>>>
>>> - Original message -
>>> From: Kiersten Gaffney 
>>> To: dev@mesos.apache.org, u...@mesos.apache.org
>>> Cc: David Greenberg , Dave Lester <
>>> d...@davelester.org>, Kiersten Gaffney 
>>> Subject: Vote on #MesosCon proposals, deadline Friday March 25
>>> Date: Sat, Mar 19, 2016 8:11 AM
>>>
>>>
>>> Please take a few minutes the next few days and review what members of
>>> the
>>> community have submitted!
>>>
>>> Voting forms close Friday, March 25, 2016, 11:55 PST
>>>
>>> A total of 154 proposals were submitted in time for #MesosCon review, up
>>> significantly from 63 submitted for last year’s conference. Similar to
>>> last
>>> year, the MesosCon program committee is opening these proposals up for
>>> community review/feedback to better-inform our decisions about what
>>> should
>>> be included in the program.
>>>
>>> In order to make it easier to review a subset of the proposals, we’ve
>>> segmented them based upon two loose themes: Developer and Users.
>>>
>>> Developers: http://bit.ly/1RpZPvj
>>>
>>> Talks on how frameworks can be used, developed, and integrate with Mesos.
>>>
>>> Users: http://bit.ly/1Mspaxp
>>>
>>> A combination of talks that are use cases (how company x uses Mesos), and
>>> operations-focused (how we deploy x, use Docker, etc).
>>>
>>> The forms above also include an opportunity to indicate which sessions
>>> you
>>> didn't see proposed but would like to attend.
>>>
>>> Thanks in advance for your participation!
>>>
>>> Kiersten, Dave, and David (Program Committee)
>>>
>>>

Re: [jira] [Created] (MESOS-4993) FetcherTest.ExtractZipFile assumes `unzip` is installed

[Tomek Janiszewski]

My bad. Fix is ready for review https://reviews.apache.org/r/45134/diff/2

-
Tomek

pon., 21.03.2016 o 22:03 użytkownik Benjamin Mahler 
napisał:

> +jie, Tomasz
>
> Looks like this new test needs a filter. Can one of you follow up with a
> fix?
>
> On Mon, Mar 21, 2016 at 12:51 PM, Neil Conway (JIRA) 
> wrote:
>
>> Neil Conway created MESOS-4993:
>> --
>>
>>  Summary: FetcherTest.ExtractZipFile assumes `unzip` is
>> installed
>>  Key: MESOS-4993
>>  URL: https://issues.apache.org/jira/browse/MESOS-4993
>>  Project: Mesos
>>   Issue Type: Task
>>   Components: fetcher, tests
>> Reporter: Neil Conway
>>
>>
>> {noformat}
>> [ RUN  ] FetcherTest.ExtractZipFile
>> W0322 06:46:42.086458  3635 fetcher.cpp:805] Begin fetcher log (stderr in
>> sandbox) for container b71f9a05-9561-402a-b33a-c9dc4f8b03cc from running
>> command: /home/vagrant/build-mesos-2/src/mesos-fetcher
>> I0322 06:46:41.895934  3653 fetcher.cpp:424] Fetcher Info:
>> {"cache_directory":"\/tmp\/mesos\/fetch\/slaves\/","items":[{"action":"BYPASS_CACHE","uri":{"extract":true,"value":"\/tmp\/0OaVy1\/from\/yMUPVR.zip"}}],"sandbox_directory":"\/tmp\/0OaVy1"}
>> I0322 06:46:41.896709  3653 fetcher.cpp:379] Fetching URI
>> '/tmp/0OaVy1/from/yMUPVR.zip'
>> I0322 06:46:41.896719  3653 fetcher.cpp:250] Fetching directly into the
>> sandbox directory
>> I0322 06:46:41.896729  3653 fetcher.cpp:187] Fetching URI
>> '/tmp/0OaVy1/from/yMUPVR.zip'
>> I0322 06:46:41.896738  3653 fetcher.cpp:167] Copying resource with
>> command:cp '/tmp/0OaVy1/from/yMUPVR.zip' '/tmp/0OaVy1/yMUPVR.zip'
>> I0322 06:46:41.899859  3653 fetcher.cpp:84] Extracting with command:
>> unzip -o -d '/tmp/0OaVy1' '/tmp/0OaVy1/yMUPVR.zip'
>> sh: unzip: command not found
>> Failed to fetch '/tmp/0OaVy1/from/yMUPVR.zip': Failed to extract: command
>> unzip -o -d '/tmp/0OaVy1' '/tmp/0OaVy1/yMUPVR.zip' exited with status: 32512
>>
>> End fetcher log for container b71f9a05-9561-402a-b33a-c9dc4f8b03cc
>> E0322 06:46:42.087045  3635 fetcher.cpp:520] Failed to run mesos-fetcher:
>> Failed to fetch all URIs for container
>> 'b71f9a05-9561-402a-b33a-c9dc4f8b03cc' with exit status: 256
>> /mesos-2/src/tests/fetcher_tests.cpp:688: Failure
>> (fetch).failure(): Failed to fetch all URIs for container
>> 'b71f9a05-9561-402a-b33a-c9dc4f8b03cc' with exit status: 256
>> [  FAILED  ] FetcherTest.ExtractZipFile (227 ms)
>> [--] 1 test from FetcherTest (227 ms total)
>> {noformat}
>>
>> Similarly:
>>
>> {noformat}
>> [  FAILED  ] FetcherTest.ExtractZipFile
>> [  FAILED  ] FetcherTest.ExtractInvalidZipFile
>> [  FAILED  ] FetcherTest.ExtractZipFileWithDuplicatedEntries
>> {noformat}
>>
>> We should handle missing {{unzip}} more gracefully, e.g., skip the test.
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.4#6332)
>>
>

Re: Contributor request

[Tomek Janiszewski]

Hi

Vinod has already  added me and I successfully assigned to MESOS-3243.

Thanks
Tomek
czw., 17 mar 2016, 00:45 użytkownik Artem Harutyunyan 
napisał:

> Hi Tomek,
>
> Sorry for the delay. Just tried to add you but couldn't find you. Which
> email did you use (jani...@gmail.com does appear to be in the list of
> registered users).
>
> Artem.
>
> On Fri, Mar 11, 2016 at 6:48 AM, Tomek Janiszewski 
> wrote:
>
> > Please add me as contributor in the Mesos JIRA project. My Apache JIRA's
> > username: janisz
> >
> > Thanks!
> >
>

Unzip should work in non interactive mode

[Tomek Janiszewski]

Hi

Consider situation when deployed zip file is malformed and contains
duplicated files .
When fetcher downloads malformed zip file, that contains duplicated files
(e.g., dist zips generated by gradle) and try to uncompress it, deployment
hang in staged phase because unzip prompt if file should be replaced. unzip
should overwrite this file or break with error. I created issue for this
MESOS-4885
It looks like easy fix, anyone want to shepherd it?

Best
Tomek

Re: Unzip should work in non interactive mode

[Tomek Janiszewski]

Patch is ready https://reviews.apache.org/r/45057/diff/1/

pt., 18.03.2016 o 16:43 użytkownik Jie Yu  napisał:

> I can shepherd it. Do you have a patch ready?
>
> - Jie
>
> On Fri, Mar 18, 2016 at 3:13 AM, Tomek Janiszewski 
> wrote:
>
> > Hi
> >
> > Consider situation when deployed zip file is malformed and contains
> > duplicated files .
> > When fetcher downloads malformed zip file, that contains duplicated files
> > (e.g., dist zips generated by gradle) and try to uncompress it,
> deployment
> > hang in staged phase because unzip prompt if file should be replaced.
> unzip
> > should overwrite this file or break with error. I created issue for this
> > MESOS-4885
> > It looks like easy fix, anyone want to shepherd it?
> >
> > Best
> > Tomek
> >
>

Re: GSoC query

[Tomek Janiszewski]

Hi

Unfortunately, I couldn't attend the meeting. I prepared GSoC proposal
(Mesos on ARM) that I want submit to Apache Foundation
https://docs.google.com/document/d/1zbms2jQfExuIm6g-adqaXjFpPif6OsqJ84KAgMrOjHQ/edit?usp=sharing
Is anyone interested in collaboration/mentoring?

Thanks
Tomek

pt., 4.03.2016 o 09:02 użytkownik haosdent  napisał:

> I could found some past gsoc ideas in mesos, maybe you could have a look
> first.
>
> https://issues.apache.org/jira/browse/MESOS-1016?jql=project%20%3D%20MESOS%20AND%20text%20~%20gsoc
>
> And I not sure whether Mesos take parts in GSOC this year or not. You may
> join our next community sync (March 10, 9pm – 10pm PST) and discuss. :)
>
> On Fri, Mar 4, 2016 at 3:01 AM, Disha Singh 
> wrote:
>
> > Hi everyone,
> >
> > Apache has got selected for GSoC 2016 so, I wanted to apply for a project
> > in Mesos, but there are no ideas related to Mesos in the GSoC ideas list,
> > but since there is an option for suggest your own idea, I wanted to ask
> if
> > I can still work under mesos if I manage to find work that can be taken
> up
> > for this summer.
> > the ideas page given on google-melange website is :
> > http://s.apache.org/gsoc2016ideas
> > <
> >
> http://www.google.com/url?q=http%3A%2F%2Fs.apache.org%2Fgsoc2016ideas&sa=D&sntz=1&usg=AFQjCNG4sqG-S9lndraXUnmYK-RVVYK--Q
> > >
> >
> > Thanks!
> >
> > -Disha
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Contributor request

[Tomek Janiszewski]

Please add me as contributor in the Mesos JIRA project. My Apache JIRA's
username: janisz

Thanks!

Re: GSoC query

[Tomek Janiszewski]

Hi

I also consider participating in GSoC. It will be great if shepard/mentors
pick some issues that could be done during GSoC and bring value for
community. Personally I'd like to work on
https://issues.apache.org/jira/plugins/servlet/mobile#issue/MESOS-2021.

Best
Tomek

czw., 3 mar 2016, 20:02 użytkownik Disha Singh 
napisał:

> Hi everyone,
>
> Apache has got selected for GSoC 2016 so, I wanted to apply for a project
> in Mesos, but there are no ideas related to Mesos in the GSoC ideas list,
> but since there is an option for suggest your own idea, I wanted to ask if
> I can still work under mesos if I manage to find work that can be taken up
> for this summer.
> the ideas page given on google-melange website is :
> http://s.apache.org/gsoc2016ideas
> <
> http://www.google.com/url?q=http%3A%2F%2Fs.apache.org%2Fgsoc2016ideas&sa=D&sntz=1&usg=AFQjCNG4sqG-S9lndraXUnmYK-RVVYK--Q
> >
>
> Thanks!
>
> -Disha
>

Re: Configuration file?

[Tomek Janiszewski]

Hi all

It looks simple for the first sight. Marco, I can work on it.

-
Tomek

wt., 24 lis 2015, 17:49 Marco Massenzio użytkownik 
napisał:

> Thank you for asking :)
>
> The idea is pretty simple (and not even original, it's the "Facade
> pattern"): essentially we would define a YAML syntax for the various
> configuration flags that Mesos ({Master, Agent}) define, possibly grouping
> them by "topic" and then write a few python classes, that read in the YAML
> configuration and emit a set of flags that reflect the caller intent, then
> invoke the appropriate ./bin/mesos-{master,slave}.sh script.
>
> (variation on the theme for installed packages)
>
> E.g.:
>
> # Configuration /opt/mesos/config-master.yml
>
> ip: 192.168.1.101
>
> zk:
>   url: zk://192.168.1.220:2181
>   quorum: 3
>
> directories:
>   work: /var/run/mesos
>   log: /var/log/mesos/master.log
>
> Execute with:
>
>   ./mesos-wrapper.py --run master --config /opt/mesos/config-master.yml
> --no-ssl \
>  [other script-specific options]
>
> would generate something along the lines of:
>
>   /opt/mesos/bin/mesos-master.sh --ip=192.168.1.101 \
> --zk=zk://192.168.1.220:2181 --quorum=3 \
> --work_dir=/var/run/mesos --log_dir=/var/log/mesos/master.log
>
> (example greatly contrived and probably pointless, but hopefully gives you
> the idea).
>
> The point is that leveraging Python and the existing YAML libraries, this
> would be pretty quick to implement, would leave Mesos per se completely
> untouched, and would be easy to maintain (add/remove flags as needed;
> enforce deprecation cycles; etc.)
>
> There's probably a ton of detail I'm missing, but you get the point.
>
> Cheers,
> M.
>
> On Tuesday, November 24, 2015, tommy xiao  wrote:
>
> > how to do that? Marco
> >
> > 2015-11-24 3:54 GMT+08:00 Marco Massenzio  > >:
> >
> > > I was thinking along the same lines, with a slightly more "modern"
> > approach
> > > :)
> > >
> > > My idea was to write a thin Python layer that reads a configuration
> YAML
> > > file (possibly with "override" flags) and then invokes
> > mesos-{master,slave}
> > > with the appropriate flags.
> > >
> > > By using YAML, we would also gain the ability to have more intuitive
> > > syntax; grouping flags by function; and make it extensible.
> > >
> > > Any takers who may want to work together on this one?
> > >
> > > --
> > > *Marco Massenzio*
> > > Distributed Systems Engineer
> > > http://codetrips.com
> > >
> > > On Mon, Nov 23, 2015 at 11:18 AM, Vinod Kone  > > wrote:
> > >
> > > > We had this discussion a long while ago and the argument was that we
> > > > already have a configuration file of sorts. It is a bash script with
> > one
> > > > flag per line that sets the environment. Is this not sufficient?
> > > >
> > > > Example:
> > > >
> > > > config.sh
> > > > 
> > > > MESOS_WORK_DIR="/var/run/mesos"
> > > > MESOS_QUORUM=2
> > > >
> > > > $ source config.sh
> > > > $ ./bin/mesos-master.sh
> > > >
> > > >
> > > >
> > > > On Mon, Nov 23, 2015 at 10:19 AM, Jojy Varghese  > >
> > > > wrote:
> > > >
> > > > > Thanks for bringing this topic up Alex. I have been thinking about
> > the
> > > > same
> > > > > and was wondering if we can have subsystem specific flags and some
> > > scheme
> > > > > where there can be a namespace instead of a flat space. And as alex
> > > > > suggested, a configuration to represent this?
> > > > >
> > > > > -jojy
> > > > > On Mon, Nov 23, 2015 at 9:32 AM tommy xiao  > > wrote:
> > > > >
> > > > > > please file a issue to tracking this proposal
> > > > > >
> > > > > > 2015-11-23 21:53 GMT+08:00 Klaus Ma  > >:
> > > > > >
> > > > > > > +1, that's helpful :).
> > > > > > >
> > > > > > > For the detail of implementing such as auto re-load, I think we
> > can
> > > > let
> > > > > > > owner/shepherd to decide :).
> > > > > > >
> > > > > > > 
> > > > > > > Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> > > > > > > Platform Symphony/DCOS Development & Support, STG, IBM GCG
> > > > > > > +86-10-8245 4084 | klaus1982...@gmail.com  |
> > http://k82.me
> > > > > > >
> > > > > > > On Mon, Nov 23, 2015 at 9:40 PM, Adam Avilla  > > wrote:
> > > > > > >
> > > > > > > > +1 I think it would be helpful.
> > > > > > > >
> > > > > > > > This may be orthogonal / feature creep, but would it be
> > possible
> > > to
> > > > > > have
> > > > > > > > the config file be able to be safely reloaded with a HUP or
> > > > > appropriate
> > > > > > > > signal?
> > > > > > > >
> > > > > > > > On Mon, Nov 23, 2015 at 5:32 AM, Guangya Liu <
> > gyliu...@gmail.com 
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > +1000, introducing a new configuration file for mesos
> master
> > > and
> > > > > > slave
> > > > > > > > can
> > > > > > > > > help end user take the configuration file as the source of
> > all
> > > > > flags.
> > > > > > > > >
> > > > > > > > > The OpenStack is also using same way to manage all of the
> > > flags,
> > > > it
> > > > > > is
> > > > > > > > > putting all f