Re: Time Zone information in TimeInfo

[Zameer Manji]

The TODO made me think that the time information here could be timezone
dependent in some cases.

If it's intended to always represent the time since the Unix epoch then TZ
info is not useful.

I think that comment should be removed for clarity.

On Mon, Mar 6, 2017 at 8:38 PM, Neil Conway  wrote:

> I always found that TODO confusing. If a `TimeInfo` is intended to
> represent the amount of time that has elapsed since the (Unix) epoch,
> I would expect it to be timezone independent. Can you clarify why
> having TZ info would be useful?
>
> Neil
>
> On Mon, Mar 6, 2017 at 7:51 PM, Zameer Manji  wrote:
> > Hey,
> >
> > I noticed there is a TODO on the TimeInfo for adding Time Zone
> information.
> > ```
> > /**
> >  * Represents time since the epoch, in nanoseconds.
> >  */
> > message TimeInfo {
> >   required int64 nanoseconds = 1;
> >
> >   // TODO(josephw): Add time zone information, if necessary.
> > }
> > ```
> >
> > Since there is no TZ information attached the timestamp, should
> frameworks
> > assume that the Mesos Master system TZ is the same as the framework TZ?
> > That is what I'm thinking of doing, but I'm not sure what was the
> intention
> > of the authors of the API.
> >
> > Also, would it be possible to attach TZ information? It would make
> > understanding the TimeInfo much easier when it is received by the
> framework.
> >
> > --
> > Zameer Manji
>
> --
> Zameer Manji
>

Re: Time Zone information in TimeInfo

[Neil Conway]

I always found that TODO confusing. If a `TimeInfo` is intended to
represent the amount of time that has elapsed since the (Unix) epoch,
I would expect it to be timezone independent. Can you clarify why
having TZ info would be useful?

Neil

On Mon, Mar 6, 2017 at 7:51 PM, Zameer Manji  wrote:
> Hey,
>
> I noticed there is a TODO on the TimeInfo for adding Time Zone information.
> ```
> /**
>  * Represents time since the epoch, in nanoseconds.
>  */
> message TimeInfo {
>   required int64 nanoseconds = 1;
>
>   // TODO(josephw): Add time zone information, if necessary.
> }
> ```
>
> Since there is no TZ information attached the timestamp, should frameworks
> assume that the Mesos Master system TZ is the same as the framework TZ?
> That is what I'm thinking of doing, but I'm not sure what was the intention
> of the authors of the API.
>
> Also, would it be possible to attach TZ information? It would make
> understanding the TimeInfo much easier when it is received by the framework.
>
> --
> Zameer Manji

Re: Welcome Kevin Klues as a Mesos Committer and PMC member!

[haosdent]

Congrats Kevin! Well deserved!

On Tue, Mar 7, 2017 at 1:49 AM, Vikrama Ditya  wrote:

> Congratulations Kevin from nvidians, well deserved and thanks for all your
> effort.
>
> Regards
> --
> Vikram
>
> -Original Message-
> From: Abhishek Dasgupta [mailto:a10gu...@linux.vnet.ibm.com]
> Sent: Wednesday, March 01, 2017 10:27 PM
> To: dev@mesos.apache.org
> Subject: Re: Welcome Kevin Klues as a Mesos Committer and PMC member!
>
> Hi Kevin,
>
> Hearty congratulations to you, Kevin..well deserved achievement..
>
> Thanks,
>
> Abhishek
>
>
> On Thursday 02 March 2017 03:35 AM, Benjamin Mahler wrote:
> > Hi all,
> >
> > Please welcome Kevin Klues as the newest committer and PMC member of
> > the Apache Mesos project.
> >
> > Kevin has been an active contributor in the project for over a year,
> > and in this time he made a number of contributions to the project:
> > Nvidia GPU support [1], the containerization side of POD support (new
> > container init process), and support for "attach" and "exec" of
> > commands within running containers [2].
> >
> > Also, Kevin took on an effort with Haris Choudhary to revive the CLI
> > [3] via a better structured python implementation (to be more
> > accessible to
> > contributors) and a more extensible architecture to better support
> > adding new or custom subcommands. The work also adds a unit test
> > framework for the CLI functionality (we had no tests previously!). I
> > think it's great that Kevin took on this much needed improvement with
> > Haris, and I'm very much looking forward to seeing this land in the
> project.
> >
> > Here is his committer eligibility document for perusal:
> > https://docs.google.com/document/d/1mlO1yyLCoCSd85XeDKIxTYyboK_uiOJ4Uw
> > r6ruKTlFM/edit
> >
> > Thanks!
> > Ben
> >
> > [1] http://mesos.apache.org/documentation/latest/gpu-support/
> > [2]
> > https://docs.google.com/document/d/1nAVr0sSSpbDLrgUlAEB5hKzCl482NSVk8V
> > 0D56sFMzU
> > [3]
> > https://docs.google.com/document/d/1r6Iv4Efu8v8IBrcUTjgYkvZ32WVscgYqrD
> > 07OyIglsA/
> >
>
>
> 
> ---
> This email message is for the sole use of the intended recipient(s) and
> may contain
> confidential information.  Any unauthorized review, use, disclosure or
> distribution
> is prohibited.  If you are not the intended recipient, please contact the
> sender by
> reply email and destroy all copies of the original message.
> 
> ---
>



-- 
Best Regards,
Haosdent Huang

Time Zone information in TimeInfo

[Zameer Manji]

Hey,

I noticed there is a TODO on the TimeInfo for adding Time Zone information.
```
/**
 * Represents time since the epoch, in nanoseconds.
 */
message TimeInfo {
  required int64 nanoseconds = 1;

  // TODO(josephw): Add time zone information, if necessary.
}
```

Since there is no TZ information attached the timestamp, should frameworks
assume that the Mesos Master system TZ is the same as the framework TZ?
That is what I'm thinking of doing, but I'm not sure what was the intention
of the authors of the API.

Also, would it be possible to attach TZ information? It would make
understanding the TimeInfo much easier when it is received by the framework.

-- 
Zameer Manji

[GitHub] mesos issue #205: Clarify existence of FrameworkID in SUBSCRIBE calls.

[aaronjwood]

Github user aaronjwood commented on the issue:

https://github.com/apache/mesos/pull/205
  
@hatred No problem, thanks for the help!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos issue #205: Clarify existence of FrameworkID in SUBSCRIBE calls.

[hatred]

Github user hatred commented on the issue:

https://github.com/apache/mesos/pull/205
  
Thanks for the PR. I couldn't find a way to assign myself as a reviewer 
here. I would review this and help get it committed.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [VOTE] Release Apache Mesos 1.2.0 (rc2)

[Jie Yu]

-0

I wanna fix MESOS-7208  which
affects all tasks that are launched as non-root using container image.

But this is not a new regression because it exists in 1.1.0, thus I am a -0

- Jie

On Fri, Mar 3, 2017 at 4:08 PM, Vinod Kone  wrote:

> +1 (binding)
>
> Since the perf and flaky test that I reported earlier doesn't seem to be
> blockers.
>
> On Fri, Mar 3, 2017 at 4:01 PM, Adam Bordelon  wrote:
>
> > I haven't heard any -1's so I'm going to go ahead and vote myself, from a
> > DC/OS perspective:
> >
> > +1 (binding)
> >
> > I ran 1.2.0-rc2 through the DC/OS integration tests on top of the
> > 1.9.0-rc1, which covers many Mesos features and tests multiple
> frameworks.
> > See CI results of https://github.com/dcos/dcos/pull/1295
> >
> > This was then merged into DC/OS 1.9.0-rc2 which passed another suite of
> > integration tests. Available for testing at https://dcos.io/releases/1.9
> .
> > 0-rc2/
> >
> >
> > On Thu, Mar 2, 2017 at 12:02 AM, Adam Bordelon 
> wrote:
> >
> >> TL;DR: No consensus yet. Let's extend the vote for a day or two, until
> we
> >> have 3 +1s or a legit -1.
> >> During that time we can test further, and investigate any issues that
> >> have shown up.
> >>
> >> Here's a summary of what's been reported on the 1.2.0-rc2 vote thread:
> >>
> >> - There was a perf core dump on ASF CI, which is not necessarily a
> >> blocker:
> >> MESOS-7160  Parsing of perf version segfaults
> >>   Perhaps fixed by backporting MESOS-6982: PerfTest.Version fails on
> >> recent Arch Linux
> >>
> >> - There were a couple of (known/unsurprising) flaky tests:
> >> MESOS-7185  DockerRuntimeIsolatorTest.ROOT_INTERNET_CURL_
> DockerDefaultEntryptRegistryPuller
> >> is flaky
> >> MESOS-4570  DockerFetcherPluginTest.INTERNET_CURL_FetchImage seems
> flaky.
> >>
> >> - If we were to have an rc3, the following Critical bugs could be
> >> included:
> >> MESOS-7050  IOSwitchboard FDs leaked when containerizer launch fails --
> >> leads to deadlock
> >> MESOS-6982  PerfTest.Version fails on recent Arch Linux
> >>
> >> - Plus doc updates:
> >> MESOS-7188 Add documentation for Debug APIs to Operator API doc
> >> MESOS-7189 Add nested container launch/wait/kill APIs to agent API
> >> docs.
> >>
> >>
> >> On Wed, Mar 1, 2017 at 11:30 AM, Neil Conway 
> >> wrote:
> >>
> >>> The perf core dump might be addressed if we backport this change:
> >>>
> >>> https://reviews.apache.org/r/56611/
> >>>
> >>> Although my guess is that this isn't a severe problem: for some
> >>> as-yet-unknown reason, running `perf` on the host segfaulted, which
> >>> causes the test to fail.
> >>>
> >>> Neil
> >>>
> >>> On Wed, Mar 1, 2017 at 11:09 AM, Vinod Kone 
> >>> wrote:
> >>> > Tested on ASF CI.
> >>> >
> >>> > Saw 2 configurations fail. One was the perf core dump issue
> >>> > . Other is a known
> >>> (since
> >>> > 0..28.0) flaky test with Docker fetcher plugin
> >>> > .
> >>> >
> >>> > Withholding the vote until we know the severity of the perf core
> dump.
> >>> >
> >>> >
> >>> > *Revision*: b9d8202a7444d0d1e49476bfc9817eb4583beaff
> >>> >
> >>> >- refs/tags/1.1.1-rc2
> >>> >
> >>> > Configuration Matrix gcc clang
> >>> > centos:7 --verbose --enable-libevent --enable-ssl autotools
> >>> > [image: Success]
> >>> >  >>> ease/30/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--ver
> >>> bose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=
> >>> 1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%
> >>> 7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> >>> > [image: Not run]
> >>> > cmake
> >>> > [image: Success]
> >>> >  >>> ease/30/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose
> >>> %20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%
> >>> 20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%7CHadoo
> >>> p)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> >>> > [image: Not run]
> >>> > --verbose autotools
> >>> > [image: Success]
> >>> >  >>> ease/30/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--ver
> >>> bose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,
> >>> label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> >>> > [image: Not run]
> >>> > cmake
> >>> > [image: Success]
> >>> >  >>> ease/30/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose
> >>> ,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_
> >>> exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> >>> > [image: Not run]
> >>> > ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
> >>> > [image: Success]
> >>> > 

RE: Welcome Kevin Klues as a Mesos Committer and PMC member!

[Vikrama Ditya]

Congratulations Kevin from nvidians, well deserved and thanks for all your 
effort.

Regards
--
Vikram

-Original Message-
From: Abhishek Dasgupta [mailto:a10gu...@linux.vnet.ibm.com] 
Sent: Wednesday, March 01, 2017 10:27 PM
To: dev@mesos.apache.org
Subject: Re: Welcome Kevin Klues as a Mesos Committer and PMC member!

Hi Kevin,

Hearty congratulations to you, Kevin..well deserved achievement..

Thanks,

Abhishek


On Thursday 02 March 2017 03:35 AM, Benjamin Mahler wrote:
> Hi all,
>
> Please welcome Kevin Klues as the newest committer and PMC member of 
> the Apache Mesos project.
>
> Kevin has been an active contributor in the project for over a year, 
> and in this time he made a number of contributions to the project: 
> Nvidia GPU support [1], the containerization side of POD support (new 
> container init process), and support for "attach" and "exec" of 
> commands within running containers [2].
>
> Also, Kevin took on an effort with Haris Choudhary to revive the CLI 
> [3] via a better structured python implementation (to be more 
> accessible to
> contributors) and a more extensible architecture to better support 
> adding new or custom subcommands. The work also adds a unit test 
> framework for the CLI functionality (we had no tests previously!). I 
> think it's great that Kevin took on this much needed improvement with 
> Haris, and I'm very much looking forward to seeing this land in the project.
>
> Here is his committer eligibility document for perusal:
> https://docs.google.com/document/d/1mlO1yyLCoCSd85XeDKIxTYyboK_uiOJ4Uw
> r6ruKTlFM/edit
>
> Thanks!
> Ben
>
> [1] http://mesos.apache.org/documentation/latest/gpu-support/
> [2]
> https://docs.google.com/document/d/1nAVr0sSSpbDLrgUlAEB5hKzCl482NSVk8V
> 0D56sFMzU
> [3]
> https://docs.google.com/document/d/1r6Iv4Efu8v8IBrcUTjgYkvZ32WVscgYqrD
> 07OyIglsA/
>


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---