Re: Negative durations

[Benjamin Mahler]

On Fri, Mar 11, 2016 at 9:22 AM, haosdent  wrote:

> I saw we use Seconds(-1) represent infinity in current code.
>
> ```
> ./3rdparty/libprocess/include/process/future.hpp:  bool await(const
> Duration& duration = Seconds(-1)) const;
> ./3rdparty/libprocess/include/process/latch.hpp:  bool await(const
> Duration& duration = Seconds(-1));
> ./3rdparty/libprocess/include/process/process.hpp:bool wait(const UPID&
> pid, const Duration& duration = Seconds(-1));
> ./3rdparty/libprocess/include/process/process.hpp:bool wait(const
> ProcessBase& process, const Duration& duration = Seconds(-1));
> ./3rdparty/libprocess/include/process/process.hpp:bool wait(const
> ProcessBase* process, const Duration& duration = Seconds(-1));
> ./3rdparty/libprocess/src/process.cpp:  if (duration == Seconds(-1)) {
> ```
>

Those examples have unfortunate style, we would use Option and
default to None() if we were to update these.


>
> On Fri, Mar 11, 2016 at 12:14 AM, Joris Van Remoortere <
> jo...@mesosphere.io>
> wrote:
>
> > Duration and TimePoint were introduced to map to the types in C++ (
> > http://en.cppreference.com/w/cpp/chrono).
> >
> > Duration is negative so as not to surprise users when they do TimePoints
> A
> > - B and end up with a positive duration when B > A. You could imagine a
> > user of these writing code to check if their maintenance window is in the
> > past:
> >
> > Duration remaining = Now - Scheduled;
> > if (remaining < 0) {
> >   // Don't use offer.
> > } else {
> >   // Still `remaining` time to use offer.
> > }
> >
> > This logic would compile correctly and likely pass review because it is
> > intuitive; however, if duration was an absolute value, then it would be a
> > bug.
> >
> > To represent infinity we currently wrap the Duration with an Option. The
> > None state represents infinity. You can find this in the protobufs.
> >
> > —
> > *Joris Van Remoortere*
> > Mesosphere
> >
> > On Wed, Mar 9, 2016 at 11:29 PM, Alexander Rojas <
> alexan...@mesosphere.io>
> > wrote:
> >
> > > IMO durations should not be negative. The problem with having them
> define
> > > an infinite period is the following:
> > >
> > > Lets say you want to compute the duration between two durations A and
> B:
> > >   C = A-B;
> > > if A < B, C is negative and it will be infinite.
> > >
> > > I one want’s to check for the case mentioned in [1] about sleeping 0
> > > marked with a negative duration, I think adding an explicit `if` is
> > better
> > > since it reflects the intention.
> > >
> > > So in to conclude:
> > >
> > > 1. Duration operations should always be positive so A-B is effectively
> > > |A.underlying_type - B.underlying_type|.
> > > 2. We do need a constant or an specific trait to represent an infinite
> > > duration.
> > >
> > > > On 09 Mar 2016, at 17:20, Klaus Ma  wrote:
> > > >
> > > > One case I can image is to use negative value for forever duration?
> > > >
> > > > 
> > > > Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> > > > Platform OpenSource Technology, STG, IBM GCG
> > > > +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
> > > >
> > > > On Wed, Mar 9, 2016 at 8:21 PM, Alex Rukletsov 
> > > wrote:
> > > >
> > > >> Folks,
> > > >>
> > > >> I've recently realized that durations we use in mesos (stout's
> > > `Duration`
> > > >> and `DurationInfo` protobuf) are based on signed integers. Negative
> > > >> duration concept is a bit strange to me, so I googled around a bit
> and
> > > >> found an interesting thread [1].
> > > >>
> > > >> Was it an explicit intention to allow `Duration`s to be negative? Do
> > we
> > > use
> > > >> this feature? If yes, maybe we can introduce a class representing
> time
> > > >> delta (can be negative) and base `Duration` on top of it
> guaranteeing
> > > it is
> > > >> always non-negative?
> > > >>
> > > >> My ultimate intention is to avoid boilerplate code that validates
> > every
> > > >> single instance of `Duration` in the codebase. I'd rather have a
> class
> > > with
> > > >> guarantees certain invariants.
> > > >>
> > > >> [1]
> > > https://internals.rust-lang.org/t/unsigned-version-of-duration/893/2
> > > >>
> > >
> > >
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: RFC: RevocableInfo Changes

[Klaus Ma]

The patches are updated accordingly; JIRA: MESOS-3888 
 , RR: 
https://reviews.apache.org/r/40375/ .

Thanks
klaus

On Saturday, March 12, 2016 at 11:09:46 AM UTC+8, Benjamin Mahler wrote:
>
> Hey folks,
>
> In the resource allocation working group we've been looking into a few 
> projects that will make the allocator able to offer out resources as 
> revocable. For example:
>
> -We'll want to eventually allocate resources as revocable _by default_, 
> only allowing non-revocable when there are guarantees put in place (static 
> reservations or quota).
>
> -On the path to revocable by default, we can incrementally start to offer 
> certain resources as revocable. Consider when quota is set but the role 
> isn't using all of the quota. The unallocated quota can be offered to other 
> roles, but it should be revocable because we may revoke them should the 
> quota'ed role want to use the resources. Unused reservations fall into a 
> similar category.
>
> -Going revocable by default also allows us to enforce fairness in a 
> dynamically changing cluster by revoking resources as weights are changed, 
> frameworks are added or removed, etc.
>
> In this context, "revocable" means that the resources may be taken away 
> and the container will be destroyed. The meaning of "revocable" in the 
> context of usage oversubscription includes this, but also the container may 
> experience a throttling (e.g. lower cpu shares, less network priority, etc).
>
> For this reason, and because we internally need to distinguish revocable 
> resources between the those that are generated by usage oversubscription 
> and those that are generated by the allocator, we're thinking of the 
> following change to the API:
>
>
>
> -  message RevocableInfo {}
> +  message RevocableInfo {
> +message ThrottleInfo {}
> +
> +// If set, indicates that the resources may be throttled at
> +// any time. Throttle-able resoruces can be used for tasks
> +// that do not have strict performance requirements and are
> +// capable of handling being throttled.
> +optional ThrottleInfo throttle_info;
> +  }
>
>// If this is set, the resources are revocable, i.e., any tasks or
> -  // executors launched using these resources could get preempted or
> -  // throttled at any time. This could be used by frameworks to run
> -  // best effort tasks that do not need strict uptime or performance
> +  // executors launched using these resources could be terminated at
> +  // any time. This could be used by frameworks to run
> +  // best effort tasks that do not need strict uptime
>// guarantees. Note that if this is set, 'disk' or 'reservation'
>// cannot be set.
>optional RevocableInfo revocable = 9;
>
>
>
> Essentially we want to distinguish between revocable and revocable + 
> throttle-able. This is because usage-oversubscription generates 
> throttle-able revocable resources, whereas the allocator does not. This 
> also solves our problem of distinguishing between these two kinds of 
> revocable resources internally.
>
> Feedback welcome!
>
> Ben
>
>

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

[Gilbert Song]

@Kevin, thanks for writing it down in detail. It sounds good that a more
concrete
schema is designed to generally solve similar auth problem.

Just have two potential issues inlined below:

On Tue, Mar 15, 2016 at 5:39 PM, Kevin Klues  wrote:

> Yeah, option 2.
>
> I was trying to expand on Avinash's suggestion and make it a bit more
> concrete in terms of what was being proposed. Needing to reload the
> agent just to update the list of credentials it accepts seems
> undesirable though.
>
> Maybe we could have a way to start the agent with a default config (by
> iterating on the schema from my previous email), but allow newly
> launched frameworks to somehow update the config on the fly through a
>

Will it be too expensive to update all agents every time a new framework
joins (handling consensus problem as well)?


> file in their sandbox that follows the same schema.
>

Does that mean the file in sandbox should be exposed to each other?


> On Tue, Mar 15, 2016 at 5:25 PM, Jie Yu  wrote:
> > Kevin, are you suggesting option 2 and having a config file like the
> above?
> >
> > I think another downside of a per-agent config is that it's hard to
> > maintain this. What if a new framework joins and has a new credential for
> > the docker images. Do we need to restart the agent to reload the config?
> >
> > - Jie
> >
> > On Tue, Mar 15, 2016 at 1:25 PM, Kevin Klues  wrote:
> >
> >> Can we be a bit more concrete here and try to build up a schema for
> this.
> >> Maybe something like:
> >>
> >> {
> >>   [
> >> {
> >>   "service" : "docker",
> >>   "registries" :
> >>   [
> >> "uri" : "",
> >> "default_credentials" :
> >> {
> >>   "type" : "",
> >>   "credential" :
> >>   {
> >>   // Custom based on type...
> >>   }
> >> },
> >> "image_credentials" :
> >> [
> >>   {
> >> "image_name" : "",
> >> "type" : "",
> >> "credential" :
> >> {
> >>   // Custom based on type...
> >> },
> >>   },
> >>   ...
> >> ],
> >> ...
> >>   ]
> >>   ...
> >> },
> >> ...
> >>   ]
> >> }
> >>
> >>
> >> On Tue, Mar 15, 2016 at 12:57 PM, Jie Yu  wrote:
> >> >>
> >> >> Yeah I was thinking having the JSON as a dictionary with keys being
> the
> >> >> registry URI (appc/docker) and the values being credentials (which
> will
> >> be
> >> >> a dictionary as well I guess).
> >> >
> >> >
> >> > Using registry URI as the key is problematic. Think about the public
> >> docker
> >> > hub. Different frameworks might want to use different credentials to
> >> access
> >> > their docker images.
> >> >
> >> > - Jie
> >> >
> >> > On Tue, Mar 15, 2016 at 11:52 AM, Avinash Sridharan <
> >> avin...@mesosphere.io
> >> >
> >> > wrote:
> >> >
> >> >> On Tue, Mar 15, 2016 at 11:43 AM, Vinod Kone 
> >> wrote:
> >> >>
> >> >> > moved core@ to *bcc*
> >> >> >
> >> >> > On Tue, Mar 15, 2016 at 11:18 AM, Avinash Sridharan <
> >> >> avin...@mesosphere.io
> >> >> > > wrote:
> >> >> >
> >> >> >> Why not follow option 2, but instead of passing the agent
> >> credentials,
> >> >> >> pass a location to the flag where credentials for the registry
> can be
> >> >> found
> >> >> >> (in JSON)? The frameworks can set credentials (maybe registry
> name or
> >> >> URL
> >> >> >> to the registry), and the credentials can be learnt from the JSON
> >> >> config.
> >> >> >>
> >> >> >
> >> >> > What if we need credentials for multiple-registries? Have a JSON
> with
> >> one
> >> >> > credential per registry I guess? But if possible, I would love to
> >> solve
> >> >> > this more generally as possible; as Gilbert mentioned, this is not
> a
> >> >> > problem just for Docker images but any URIs that need AuthN.
> >> >> >
> >> >> Yeah I was thinking having the JSON as a dictionary with keys being
> the
> >> >> registry URI (appc/docker) and the values being credentials (which
> will
> >> be
> >> >> a dictionary as well I guess).
> >> >>
> >> >>
> >> >> --
> >> >> Avinash Sridharan, Mesosphere
> >> >> +1 (323) 702 5245
> >> >>
> >>
> >>
> >>
> >> --
> >> ~Kevin
> >>
>
>
>
> --
> ~Kevin
>

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

[Vinod Kone]

I actually think the way DockerContainerizer currently does it is
reasonable and allows each container to talk to a potentially different
registry using unique credentials. Given the multitude of AuthN schemes, it
is probably better to leave the problem of fetching CommandInfo.URIs that
need AuthN to fetcher modules.

On Tue, Mar 15, 2016 at 5:39 PM, Kevin Klues  wrote:

> Yeah, option 2.
>
> I was trying to expand on Avinash's suggestion and make it a bit more
> concrete in terms of what was being proposed. Needing to reload the
> agent just to update the list of credentials it accepts seems
> undesirable though.
>
> Maybe we could have a way to start the agent with a default config (by
> iterating on the schema from my previous email), but allow newly
> launched frameworks to somehow update the config on the fly through a
> file in their sandbox that follows the same schema.
>
> On Tue, Mar 15, 2016 at 5:25 PM, Jie Yu  wrote:
> > Kevin, are you suggesting option 2 and having a config file like the
> above?
> >
> > I think another downside of a per-agent config is that it's hard to
> > maintain this. What if a new framework joins and has a new credential for
> > the docker images. Do we need to restart the agent to reload the config?
> >
> > - Jie
> >
> > On Tue, Mar 15, 2016 at 1:25 PM, Kevin Klues  wrote:
> >
> >> Can we be a bit more concrete here and try to build up a schema for
> this.
> >> Maybe something like:
> >>
> >> {
> >>   [
> >> {
> >>   "service" : "docker",
> >>   "registries" :
> >>   [
> >> "uri" : "",
> >> "default_credentials" :
> >> {
> >>   "type" : "",
> >>   "credential" :
> >>   {
> >>   // Custom based on type...
> >>   }
> >> },
> >> "image_credentials" :
> >> [
> >>   {
> >> "image_name" : "",
> >> "type" : "",
> >> "credential" :
> >> {
> >>   // Custom based on type...
> >> },
> >>   },
> >>   ...
> >> ],
> >> ...
> >>   ]
> >>   ...
> >> },
> >> ...
> >>   ]
> >> }
> >>
> >>
> >> On Tue, Mar 15, 2016 at 12:57 PM, Jie Yu  wrote:
> >> >>
> >> >> Yeah I was thinking having the JSON as a dictionary with keys being
> the
> >> >> registry URI (appc/docker) and the values being credentials (which
> will
> >> be
> >> >> a dictionary as well I guess).
> >> >
> >> >
> >> > Using registry URI as the key is problematic. Think about the public
> >> docker
> >> > hub. Different frameworks might want to use different credentials to
> >> access
> >> > their docker images.
> >> >
> >> > - Jie
> >> >
> >> > On Tue, Mar 15, 2016 at 11:52 AM, Avinash Sridharan <
> >> avin...@mesosphere.io
> >> >
> >> > wrote:
> >> >
> >> >> On Tue, Mar 15, 2016 at 11:43 AM, Vinod Kone 
> >> wrote:
> >> >>
> >> >> > moved core@ to *bcc*
> >> >> >
> >> >> > On Tue, Mar 15, 2016 at 11:18 AM, Avinash Sridharan <
> >> >> avin...@mesosphere.io
> >> >> > > wrote:
> >> >> >
> >> >> >> Why not follow option 2, but instead of passing the agent
> >> credentials,
> >> >> >> pass a location to the flag where credentials for the registry
> can be
> >> >> found
> >> >> >> (in JSON)? The frameworks can set credentials (maybe registry
> name or
> >> >> URL
> >> >> >> to the registry), and the credentials can be learnt from the JSON
> >> >> config.
> >> >> >>
> >> >> >
> >> >> > What if we need credentials for multiple-registries? Have a JSON
> with
> >> one
> >> >> > credential per registry I guess? But if possible, I would love to
> >> solve
> >> >> > this more generally as possible; as Gilbert mentioned, this is not
> a
> >> >> > problem just for Docker images but any URIs that need AuthN.
> >> >> >
> >> >> Yeah I was thinking having the JSON as a dictionary with keys being
> the
> >> >> registry URI (appc/docker) and the values being credentials (which
> will
> >> be
> >> >> a dictionary as well I guess).
> >> >>
> >> >>
> >> >> --
> >> >> Avinash Sridharan, Mesosphere
> >> >> +1 (323) 702 5245
> >> >>
> >>
> >>
> >>
> >> --
> >> ~Kevin
> >>
>
>
>
> --
> ~Kevin
>

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

[Kevin Klues]

Yeah, option 2.

I was trying to expand on Avinash's suggestion and make it a bit more
concrete in terms of what was being proposed. Needing to reload the
agent just to update the list of credentials it accepts seems
undesirable though.

Maybe we could have a way to start the agent with a default config (by
iterating on the schema from my previous email), but allow newly
launched frameworks to somehow update the config on the fly through a
file in their sandbox that follows the same schema.

On Tue, Mar 15, 2016 at 5:25 PM, Jie Yu  wrote:
> Kevin, are you suggesting option 2 and having a config file like the above?
>
> I think another downside of a per-agent config is that it's hard to
> maintain this. What if a new framework joins and has a new credential for
> the docker images. Do we need to restart the agent to reload the config?
>
> - Jie
>
> On Tue, Mar 15, 2016 at 1:25 PM, Kevin Klues  wrote:
>
>> Can we be a bit more concrete here and try to build up a schema for this.
>> Maybe something like:
>>
>> {
>>   [
>> {
>>   "service" : "docker",
>>   "registries" :
>>   [
>> "uri" : "",
>> "default_credentials" :
>> {
>>   "type" : "",
>>   "credential" :
>>   {
>>   // Custom based on type...
>>   }
>> },
>> "image_credentials" :
>> [
>>   {
>> "image_name" : "",
>> "type" : "",
>> "credential" :
>> {
>>   // Custom based on type...
>> },
>>   },
>>   ...
>> ],
>> ...
>>   ]
>>   ...
>> },
>> ...
>>   ]
>> }
>>
>>
>> On Tue, Mar 15, 2016 at 12:57 PM, Jie Yu  wrote:
>> >>
>> >> Yeah I was thinking having the JSON as a dictionary with keys being the
>> >> registry URI (appc/docker) and the values being credentials (which will
>> be
>> >> a dictionary as well I guess).
>> >
>> >
>> > Using registry URI as the key is problematic. Think about the public
>> docker
>> > hub. Different frameworks might want to use different credentials to
>> access
>> > their docker images.
>> >
>> > - Jie
>> >
>> > On Tue, Mar 15, 2016 at 11:52 AM, Avinash Sridharan <
>> avin...@mesosphere.io
>> >
>> > wrote:
>> >
>> >> On Tue, Mar 15, 2016 at 11:43 AM, Vinod Kone 
>> wrote:
>> >>
>> >> > moved core@ to *bcc*
>> >> >
>> >> > On Tue, Mar 15, 2016 at 11:18 AM, Avinash Sridharan <
>> >> avin...@mesosphere.io
>> >> > > wrote:
>> >> >
>> >> >> Why not follow option 2, but instead of passing the agent
>> credentials,
>> >> >> pass a location to the flag where credentials for the registry can be
>> >> found
>> >> >> (in JSON)? The frameworks can set credentials (maybe registry name or
>> >> URL
>> >> >> to the registry), and the credentials can be learnt from the JSON
>> >> config.
>> >> >>
>> >> >
>> >> > What if we need credentials for multiple-registries? Have a JSON with
>> one
>> >> > credential per registry I guess? But if possible, I would love to
>> solve
>> >> > this more generally as possible; as Gilbert mentioned, this is not a
>> >> > problem just for Docker images but any URIs that need AuthN.
>> >> >
>> >> Yeah I was thinking having the JSON as a dictionary with keys being the
>> >> registry URI (appc/docker) and the values being credentials (which will
>> be
>> >> a dictionary as well I guess).
>> >>
>> >>
>> >> --
>> >> Avinash Sridharan, Mesosphere
>> >> +1 (323) 702 5245
>> >>
>>
>>
>>
>> --
>> ~Kevin
>>



-- 
~Kevin

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

[Jie Yu]

Kevin, are you suggesting option 2 and having a config file like the above?

I think another downside of a per-agent config is that it's hard to
maintain this. What if a new framework joins and has a new credential for
the docker images. Do we need to restart the agent to reload the config?

- Jie

On Tue, Mar 15, 2016 at 1:25 PM, Kevin Klues  wrote:

> Can we be a bit more concrete here and try to build up a schema for this.
> Maybe something like:
>
> {
>   [
> {
>   "service" : "docker",
>   "registries" :
>   [
> "uri" : "",
> "default_credentials" :
> {
>   "type" : "",
>   "credential" :
>   {
>   // Custom based on type...
>   }
> },
> "image_credentials" :
> [
>   {
> "image_name" : "",
> "type" : "",
> "credential" :
> {
>   // Custom based on type...
> },
>   },
>   ...
> ],
> ...
>   ]
>   ...
> },
> ...
>   ]
> }
>
>
> On Tue, Mar 15, 2016 at 12:57 PM, Jie Yu  wrote:
> >>
> >> Yeah I was thinking having the JSON as a dictionary with keys being the
> >> registry URI (appc/docker) and the values being credentials (which will
> be
> >> a dictionary as well I guess).
> >
> >
> > Using registry URI as the key is problematic. Think about the public
> docker
> > hub. Different frameworks might want to use different credentials to
> access
> > their docker images.
> >
> > - Jie
> >
> > On Tue, Mar 15, 2016 at 11:52 AM, Avinash Sridharan <
> avin...@mesosphere.io
> >
> > wrote:
> >
> >> On Tue, Mar 15, 2016 at 11:43 AM, Vinod Kone 
> wrote:
> >>
> >> > moved core@ to *bcc*
> >> >
> >> > On Tue, Mar 15, 2016 at 11:18 AM, Avinash Sridharan <
> >> avin...@mesosphere.io
> >> > > wrote:
> >> >
> >> >> Why not follow option 2, but instead of passing the agent
> credentials,
> >> >> pass a location to the flag where credentials for the registry can be
> >> found
> >> >> (in JSON)? The frameworks can set credentials (maybe registry name or
> >> URL
> >> >> to the registry), and the credentials can be learnt from the JSON
> >> config.
> >> >>
> >> >
> >> > What if we need credentials for multiple-registries? Have a JSON with
> one
> >> > credential per registry I guess? But if possible, I would love to
> solve
> >> > this more generally as possible; as Gilbert mentioned, this is not a
> >> > problem just for Docker images but any URIs that need AuthN.
> >> >
> >> Yeah I was thinking having the JSON as a dictionary with keys being the
> >> registry URI (appc/docker) and the values being credentials (which will
> be
> >> a dictionary as well I guess).
> >>
> >>
> >> --
> >> Avinash Sridharan, Mesosphere
> >> +1 (323) 702 5245
> >>
>
>
>
> --
> ~Kevin
>

Re: Backport r/44230 to 0.27 branch

[Jie Yu]

commit 5278e5cc50544ed7af28b15a1acd2b2e96a15a47
Author: Jojy Varghese 
Date:   Tue Mar 15 17:12:01 2016 -0700

Added support for FTS_SLNONE in rmdir.

Review: https://reviews.apache.org/r/44874/

commit 5c4b348c8090ce61804b7701e3b0705ced975a7e
Author: Jojy Varghese 
Date:   Tue Mar 15 17:11:54 2016 -0700

Added test for rmdir with device file.

Existing tests did not cover the case of removing directories with
special files like device files.

Review: https://reviews.apache.org/r/44873/

- Jie

On Tue, Mar 15, 2016 at 2:46 PM, Jie Yu  wrote:
> Also, I think we should fix the TODO in rmdir as well (i.e., handle
> FTS_SLNONE as well as Neil suggested).
>
> - Jie
>
> On Tue, Mar 15, 2016 at 2:39 PM, Jie Yu  wrote:
>>
>> Mesos currently has no notion of long term stable releases (i.e., LTS). I
>> think the consensus in the last community sync was to introduce LTS after
>> 1.0.
>>
>> 0.27.2 has already been released. Looks like we need 0.27.3 if we want to
>> backport it.
>>
>> I am OK with back porting it. Then the question is that whether we want to
>> backport it to other releases as well.
>>
>> - Jie
>>
>> On Tue, Mar 15, 2016 at 11:45 AM, Cong Wang 
>> wrote:
>>>
>>> Hi, all
>>>
>>> I don't know what is the process to request for a backport for Mesos
>>> stable releases and how Mesos community cares about stable releases.
>>> But... please consider to backport the following patch to at least
>>> 0.27 branch:
>>>
>>> https://reviews.apache.org/r/44230/
>>>
>>> It fixes a bug in our production which causes GC failed to prune a
>>> directory.
>>>
>>> The backport should be very straightforward. Please let me know if I
>>> can help anything.
>>>
>>> BTW, for Linux kernel we evaluate every bug fix to make sure it is
>>> backported to the right stable releases.
>>>
>>> Thanks.
>>
>>
>

Re: Backport r/44230 to 0.27 branch

[Jie Yu]

Also, I think we should fix the TODO in rmdir as well (i.e.,
handle FTS_SLNONE as well as Neil suggested).

- Jie

On Tue, Mar 15, 2016 at 2:39 PM, Jie Yu  wrote:

> Mesos currently has no notion of long term stable releases (i.e., LTS). I
> think the consensus in the last community sync was to introduce LTS after
> 1.0.
>
> 0.27.2 has already been released. Looks like we need 0.27.3 if we want to
> backport it.
>
> I am OK with back porting it. Then the question is that whether we want to
> backport it to other releases as well.
>
> - Jie
>
> On Tue, Mar 15, 2016 at 11:45 AM, Cong Wang 
> wrote:
>
>> Hi, all
>>
>> I don't know what is the process to request for a backport for Mesos
>> stable releases and how Mesos community cares about stable releases.
>> But... please consider to backport the following patch to at least
>> 0.27 branch:
>>
>> https://reviews.apache.org/r/44230/
>>
>> It fixes a bug in our production which causes GC failed to prune a
>> directory.
>>
>> The backport should be very straightforward. Please let me know if I
>> can help anything.
>>
>> BTW, for Linux kernel we evaluate every bug fix to make sure it is
>> backported to the right stable releases.
>>
>> Thanks.
>>
>
>

Re: Backport r/44230 to 0.27 branch

[Jie Yu]

Mesos currently has no notion of long term stable releases (i.e., LTS). I
think the consensus in the last community sync was to introduce LTS after
1.0.

0.27.2 has already been released. Looks like we need 0.27.3 if we want to
backport it.

I am OK with back porting it. Then the question is that whether we want to
backport it to other releases as well.

- Jie

On Tue, Mar 15, 2016 at 11:45 AM, Cong Wang  wrote:

> Hi, all
>
> I don't know what is the process to request for a backport for Mesos
> stable releases and how Mesos community cares about stable releases.
> But... please consider to backport the following patch to at least
> 0.27 branch:
>
> https://reviews.apache.org/r/44230/
>
> It fixes a bug in our production which causes GC failed to prune a
> directory.
>
> The backport should be very straightforward. Please let me know if I
> can help anything.
>
> BTW, for Linux kernel we evaluate every bug fix to make sure it is
> backported to the right stable releases.
>
> Thanks.
>

RE: Looking for shepherd (MESOS-4807)

[Yong Tang]

Thanks Benjamin and Joris for the help!

Thanks
Yong

> Subject: Re: Looking for shepherd (MESOS-4807)
> From: benjamin.bann...@mesosphere.io
> Date: Tue, 15 Mar 2016 21:29:17 +0100
> To: dev@mesos.apache.org
> 
> Hi Yong,
> 
> > I am looking for shepherd to help me on MESOS-4807. 
> > 
> > https://issues.apache.org/jira/browse/MESOS-4807
> > 
> > This issue is similar to MESOS-4806 as both of them tries to fixes issues 
> > that could parallelize the tests in mesos. Would appreciate if anyone could 
> > shepherd to help me on this issue (MESOS-4807).
> 
> Thanks for taking on fixing this issue. Joris stepped up to shepherd your 
> patch, and it looks like he already committed it.
> 
> 
> Cheers,
> 
> Benjamin
  

Re: Looking for shepherd (MESOS-4807)

[Benjamin Bannier]

Hi Yong,

> I am looking for shepherd to help me on MESOS-4807. 
> 
> https://issues.apache.org/jira/browse/MESOS-4807
> 
> This issue is similar to MESOS-4806 as both of them tries to fixes issues 
> that could parallelize the tests in mesos. Would appreciate if anyone could 
> shepherd to help me on this issue (MESOS-4807).

Thanks for taking on fixing this issue. Joris stepped up to shepherd your 
patch, and it looks like he already committed it.


Cheers,

Benjamin

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

[Kevin Klues]

Can we be a bit more concrete here and try to build up a schema for this.
Maybe something like:

{
  [
{
  "service" : "docker",
  "registries" :
  [
"uri" : "",
"default_credentials" :
{
  "type" : "",
  "credential" :
  {
  // Custom based on type...
  }
},
"image_credentials" :
[
  {
"image_name" : "",
"type" : "",
"credential" :
{
  // Custom based on type...
},
  },
  ...
],
...
  ]
  ...
},
...
  ]
}


On Tue, Mar 15, 2016 at 12:57 PM, Jie Yu  wrote:
>>
>> Yeah I was thinking having the JSON as a dictionary with keys being the
>> registry URI (appc/docker) and the values being credentials (which will
be
>> a dictionary as well I guess).
>
>
> Using registry URI as the key is problematic. Think about the public
docker
> hub. Different frameworks might want to use different credentials to
access
> their docker images.
>
> - Jie
>
> On Tue, Mar 15, 2016 at 11:52 AM, Avinash Sridharan 
> wrote:
>
>> On Tue, Mar 15, 2016 at 11:43 AM, Vinod Kone 
wrote:
>>
>> > moved core@ to *bcc*
>> >
>> > On Tue, Mar 15, 2016 at 11:18 AM, Avinash Sridharan <
>> avin...@mesosphere.io
>> > > wrote:
>> >
>> >> Why not follow option 2, but instead of passing the agent credentials,
>> >> pass a location to the flag where credentials for the registry can be
>> found
>> >> (in JSON)? The frameworks can set credentials (maybe registry name or
>> URL
>> >> to the registry), and the credentials can be learnt from the JSON
>> config.
>> >>
>> >
>> > What if we need credentials for multiple-registries? Have a JSON with
one
>> > credential per registry I guess? But if possible, I would love to solve
>> > this more generally as possible; as Gilbert mentioned, this is not a
>> > problem just for Docker images but any URIs that need AuthN.
>> >
>> Yeah I was thinking having the JSON as a dictionary with keys being the
>> registry URI (appc/docker) and the values being credentials (which will
be
>> a dictionary as well I guess).
>>
>>
>> --
>> Avinash Sridharan, Mesosphere
>> +1 (323) 702 5245
>>



-- 
~Kevin

Re: [proposal] MESOS-4610: MasterContender/MasterDetector should be loadable as modules

[Anurag Singh]

As of now, we've got Ben Hindman as the designated shepherd. Joesph Wu has
been helping us with the reviews and suggesting changes.

On Tue, Mar 15, 2016 at 1:09 PM, Vinod Kone  wrote:

> This is great to hear! @YanXu is this something you might be able to
> shepherd?
>
> On Tue, Mar 15, 2016 at 1:03 PM, Anurag Singh <
> anurag.prakash.si...@gmail.com> wrote:
>
> > Hi,
> >
> > We're inviting user and developer comments on a series of changes we have
> > been working on that would modularize MasterContender and
> MasterDetectors.
> > The goal is to allow the use of detector and contender implementations
> > other than the ones that are part of Mesos source (Standalone and
> > Zookeeper). So if one would like to use a custom leader election
> mechanism
> > (e.g. one that relies on etcd, consul, etc.), it will be possible to load
> > the implementation from a shared library. In practice, it translates to
> > using the following command line options:
> >
> > For the mesos master:
> >
> > --master_contender: The value of this command line option is the name of
> a
> > symbol (defined in a module and referenced in the value of the --modules
> > flag). The symbol refers to an object of type Module.
> For
> > an example, please see the test_contender_module.cpp file in
> > https://reviews.apache.org/r/44289/.
> >
> > For the mesos master and slave:
> >
> > --master_detector:  The value of this command line option is the name of
> a
> > symbol (defined in a module and referenced in the value of the --modules
> > flag). The symbol refers to an object of type Module. For
> > an example, please see the test_detector_module.cpp file in
> > https://reviews.apache.org/r/44289/.
> >
> > The --modules option, in addition to pointing to the shared library and
> > symbols, can be used to pass parameters (via the Parameters class) to the
> > modules in the form of key-value pairs.
> >
> > Also, please note that there is no change in the behavior of the legacy
> > --zk and --master options. They will continue to work as before.
> >
> > The following changes implement this functionality and have been under
> > review (thanks to Joseph Wu (Mesosphere) for his input):
> >
> > https://reviews.apache.org/r/44287/
> > https://reviews.apache.org/r/44288/
> > https://reviews.apache.org/r/44543/
> > https://reviews.apache.org/r/44544/
> > https://reviews.apache.org/r/44545/
> > https://reviews.apache.org/r/44546/
> > https://reviews.apache.org/r/44547/
> > https://reviews.apache.org/r/44289/
> > https://reviews.apache.org/r/44669/
> > https://reviews.apache.org/r/44670/
> >
>

Re: [proposal] MESOS-4610: MasterContender/MasterDetector should be loadable as modules

[Vinod Kone]

This is great to hear! @YanXu is this something you might be able to
shepherd?

On Tue, Mar 15, 2016 at 1:03 PM, Anurag Singh <
anurag.prakash.si...@gmail.com> wrote:

> Hi,
>
> We're inviting user and developer comments on a series of changes we have
> been working on that would modularize MasterContender and MasterDetectors.
> The goal is to allow the use of detector and contender implementations
> other than the ones that are part of Mesos source (Standalone and
> Zookeeper). So if one would like to use a custom leader election mechanism
> (e.g. one that relies on etcd, consul, etc.), it will be possible to load
> the implementation from a shared library. In practice, it translates to
> using the following command line options:
>
> For the mesos master:
>
> --master_contender: The value of this command line option is the name of a
> symbol (defined in a module and referenced in the value of the --modules
> flag). The symbol refers to an object of type Module. For
> an example, please see the test_contender_module.cpp file in
> https://reviews.apache.org/r/44289/.
>
> For the mesos master and slave:
>
> --master_detector:  The value of this command line option is the name of a
> symbol (defined in a module and referenced in the value of the --modules
> flag). The symbol refers to an object of type Module. For
> an example, please see the test_detector_module.cpp file in
> https://reviews.apache.org/r/44289/.
>
> The --modules option, in addition to pointing to the shared library and
> symbols, can be used to pass parameters (via the Parameters class) to the
> modules in the form of key-value pairs.
>
> Also, please note that there is no change in the behavior of the legacy
> --zk and --master options. They will continue to work as before.
>
> The following changes implement this functionality and have been under
> review (thanks to Joseph Wu (Mesosphere) for his input):
>
> https://reviews.apache.org/r/44287/
> https://reviews.apache.org/r/44288/
> https://reviews.apache.org/r/44543/
> https://reviews.apache.org/r/44544/
> https://reviews.apache.org/r/44545/
> https://reviews.apache.org/r/44546/
> https://reviews.apache.org/r/44547/
> https://reviews.apache.org/r/44289/
> https://reviews.apache.org/r/44669/
> https://reviews.apache.org/r/44670/
>

[proposal] MESOS-4610: MasterContender/MasterDetector should be loadable as modules

[Anurag Singh]

Hi,

We're inviting user and developer comments on a series of changes we have
been working on that would modularize MasterContender and MasterDetectors.
The goal is to allow the use of detector and contender implementations
other than the ones that are part of Mesos source (Standalone and
Zookeeper). So if one would like to use a custom leader election mechanism
(e.g. one that relies on etcd, consul, etc.), it will be possible to load
the implementation from a shared library. In practice, it translates to
using the following command line options:

For the mesos master:

--master_contender: The value of this command line option is the name of a
symbol (defined in a module and referenced in the value of the --modules
flag). The symbol refers to an object of type Module. For
an example, please see the test_contender_module.cpp file in
https://reviews.apache.org/r/44289/.

For the mesos master and slave:

--master_detector:  The value of this command line option is the name of a
symbol (defined in a module and referenced in the value of the --modules
flag). The symbol refers to an object of type Module. For
an example, please see the test_detector_module.cpp file in
https://reviews.apache.org/r/44289/.

The --modules option, in addition to pointing to the shared library and
symbols, can be used to pass parameters (via the Parameters class) to the
modules in the form of key-value pairs.

Also, please note that there is no change in the behavior of the legacy
--zk and --master options. They will continue to work as before.

The following changes implement this functionality and have been under
review (thanks to Joseph Wu (Mesosphere) for his input):

https://reviews.apache.org/r/44287/
https://reviews.apache.org/r/44288/
https://reviews.apache.org/r/44543/
https://reviews.apache.org/r/44544/
https://reviews.apache.org/r/44545/
https://reviews.apache.org/r/44546/
https://reviews.apache.org/r/44547/
https://reviews.apache.org/r/44289/
https://reviews.apache.org/r/44669/
https://reviews.apache.org/r/44670/

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

[Jie Yu]

>
> Yeah I was thinking having the JSON as a dictionary with keys being the
> registry URI (appc/docker) and the values being credentials (which will be
> a dictionary as well I guess).


Using registry URI as the key is problematic. Think about the public docker
hub. Different frameworks might want to use different credentials to access
their docker images.

- Jie

On Tue, Mar 15, 2016 at 11:52 AM, Avinash Sridharan 
wrote:

> On Tue, Mar 15, 2016 at 11:43 AM, Vinod Kone  wrote:
>
> > moved core@ to *bcc*
> >
> > On Tue, Mar 15, 2016 at 11:18 AM, Avinash Sridharan <
> avin...@mesosphere.io
> > > wrote:
> >
> >> Why not follow option 2, but instead of passing the agent credentials,
> >> pass a location to the flag where credentials for the registry can be
> found
> >> (in JSON)? The frameworks can set credentials (maybe registry name or
> URL
> >> to the registry), and the credentials can be learnt from the JSON
> config.
> >>
> >
> > What if we need credentials for multiple-registries? Have a JSON with one
> > credential per registry I guess? But if possible, I would love to solve
> > this more generally as possible; as Gilbert mentioned, this is not a
> > problem just for Docker images but any URIs that need AuthN.
> >
> Yeah I was thinking having the JSON as a dictionary with keys being the
> registry URI (appc/docker) and the values being credentials (which will be
> a dictionary as well I guess).
>
>
> --
> Avinash Sridharan, Mesosphere
> +1 (323) 702 5245
>

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

[Avinash Sridharan]

On Tue, Mar 15, 2016 at 11:43 AM, Vinod Kone  wrote:

> moved core@ to *bcc*
>
> On Tue, Mar 15, 2016 at 11:18 AM, Avinash Sridharan  > wrote:
>
>> Why not follow option 2, but instead of passing the agent credentials,
>> pass a location to the flag where credentials for the registry can be found
>> (in JSON)? The frameworks can set credentials (maybe registry name or URL
>> to the registry), and the credentials can be learnt from the JSON config.
>>
>
> What if we need credentials for multiple-registries? Have a JSON with one
> credential per registry I guess? But if possible, I would love to solve
> this more generally as possible; as Gilbert mentioned, this is not a
> problem just for Docker images but any URIs that need AuthN.
>
Yeah I was thinking having the JSON as a dictionary with keys being the
registry URI (appc/docker) and the values being credentials (which will be
a dictionary as well I guess).


-- 
Avinash Sridharan, Mesosphere
+1 (323) 702 5245

Backport r/44230 to 0.27 branch

[Cong Wang]

Hi, all

I don't know what is the process to request for a backport for Mesos
stable releases and how Mesos community cares about stable releases.
But... please consider to backport the following patch to at least
0.27 branch:

https://reviews.apache.org/r/44230/

It fixes a bug in our production which causes GC failed to prune a directory.

The backport should be very straightforward. Please let me know if I
can help anything.

BTW, for Linux kernel we evaluate every bug fix to make sure it is
backported to the right stable releases.

Thanks.

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

[Jojy Varghese]

Have we considered provisioning SSL certs and keys as a separate step 
(isolation maybe)? This could mean mounting “.ssl” volume inside the container 
for example.

-Jojy


> On Mar 15, 2016, at 11:18 AM, Avinash Sridharan  wrote:
> 
> Why not follow option 2, but instead of passing the agent credentials, pass a 
> location to the flag where credentials for the registry can be found (in 
> JSON)? The frameworks can set credentials (maybe registry name or URL to the 
> registry), and the credentials can be learnt from the JSON config.
> 
> With option 1, won't we need to mutate the frameworks to make them more 
> secure ?
> 
> On Tue, Mar 15, 2016 at 10:48 AM, Gilbert Song  > wrote:
> Hi folks,
> 
> We want to raise a discussion here, seeking suggestions about passing 
> credentials in a secure way. This relates to the JIRA MESOS-4938 
> , supporting docker private 
> registry authentication in unified containerizer. In fact, this problem is 
> not limited to docker registry. For instance, how can we support 
> CommandInfo.URIs that need credentials?
> 
> For the docker registry problem, credentials have to be included when 
> communicating with the docker auth server. We have two options here:
> 
> Option 1: Passing credentials in protobuf Image::Docker.
> Pros: This means supporting per-container docker registry, which is robust 
> because different registry can be reached by an agent, configurable by users.
> Cons: So SSL has to be enabled to encrypt the communication between master 
> and slave to prevent credentials from being seen by others. We also need to 
> make sure we don’t expose credentials in any endpoint.
> 
> Option 2: Passing credentials as an agent flag.
> Pros: Not necessary to be SSL enabled. 
> Cons: No per-container registry support (imagine a multi-tenant cluster).
> 
> Some background: How does docker containerizer solve this issue?
> In docker containerizer, we ask the framework to specify a URI for their 
> task/executor that points to the .dockercfg(now ~/.docker/config.json) which 
> contains the user and password information. The .dockercfg will be saved in 
> the sandbox by the fetcher. When we call docker pull, we set the $HOME env 
> for the subprocess to point to the sandbox so that the docker client can pick 
> up that .dockercfg when pulling images.
> 
> Any comment/advice will be absolutely welcome!
> 
> Thanks,
> Gilbert/Jie
> 
> 
> 
> -- 
> Avinash Sridharan, Mesosphere
> +1 (323) 702 5245

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

[Vinod Kone]

moved core@ to *bcc*

On Tue, Mar 15, 2016 at 11:18 AM, Avinash Sridharan 
wrote:

> Why not follow option 2, but instead of passing the agent credentials,
> pass a location to the flag where credentials for the registry can be found
> (in JSON)? The frameworks can set credentials (maybe registry name or URL
> to the registry), and the credentials can be learnt from the JSON config.
>

What if we need credentials for multiple-registries? Have a JSON with one
credential per registry I guess? But if possible, I would love to solve
this more generally as possible; as Gilbert mentioned, this is not a
problem just for Docker images but any URIs that need AuthN.

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
>

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

[Avinash Sridharan]

Why not follow option 2, but instead of passing the agent credentials, pass
a location to the flag where credentials for the registry can be found (in
JSON)? The frameworks can set credentials (maybe registry name or URL to
the registry), and the credentials can be learnt from the JSON config.

With option 1, won't we need to mutate the frameworks to make them more
secure ?

On Tue, Mar 15, 2016 at 10:48 AM, Gilbert Song 
wrote:

> Hi folks,
>
> We want to raise a discussion here, seeking suggestions about passing
> credentials in a secure way. This relates to the JIRA MESOS-4938
> , supporting docker
> private registry authentication in unified containerizer. In fact, this
> problem is not limited to docker registry. For instance, how can we support
> CommandInfo.URIs that need credentials?
>
> For the docker registry problem, credentials have to be included when
> communicating with the docker auth server. We have two options here:
>
> Option 1: Passing credentials in protobuf Image::Docker.
>
> Pros: This means supporting per-container docker registry, which is
> robust because different registry can be reached by an agent, configurable
> by users.
>
> Cons: So SSL has to be enabled to encrypt the communication between
> master and slave to prevent credentials from being seen by others. We also
> need to make sure we don’t expose credentials in any endpoint.
>
> Option 2: Passing credentials as an agent flag.
>
> Pros: Not necessary to be SSL enabled.
>
> Cons: No per-container registry support (imagine a multi-tenant cluster).
>
> Some background: How does docker containerizer solve this issue?
>
> In docker containerizer, we ask the framework to specify a URI for their
> task/executor that points to the .dockercfg(now ~/.docker/config.json)
> which contains the user and password information. The .dockercfg will be
> saved in the sandbox by the fetcher. When we call docker pull, we set the
> $HOME env for the subprocess to point to the sandbox so that the docker
> client can pick up that .dockercfg when pulling images.
>
> Any comment/advice will be absolutely welcome!
>
> Thanks,
> Gilbert/Jie
>



-- 
Avinash Sridharan, Mesosphere
+1 (323) 702 5245

[DISCUSS] Fetching Docker Images Requiring User Credentials.

[Gilbert Song]

Hi folks,

We want to raise a discussion here, seeking suggestions about passing
credentials in a secure way. This relates to the JIRA MESOS-4938
, supporting docker
private registry authentication in unified containerizer. In fact, this
problem is not limited to docker registry. For instance, how can we support
CommandInfo.URIs that need credentials?

For the docker registry problem, credentials have to be included when
communicating with the docker auth server. We have two options here:

Option 1: Passing credentials in protobuf Image::Docker.

Pros: This means supporting per-container docker registry, which is robust
because different registry can be reached by an agent, configurable by
users.

Cons: So SSL has to be enabled to encrypt the communication between master
and slave to prevent credentials from being seen by others. We also need to
make sure we don’t expose credentials in any endpoint.

Option 2: Passing credentials as an agent flag.

Pros: Not necessary to be SSL enabled.

Cons: No per-container registry support (imagine a multi-tenant cluster).

Some background: How does docker containerizer solve this issue?

In docker containerizer, we ask the framework to specify a URI for their
task/executor that points to the .dockercfg(now ~/.docker/config.json)
which contains the user and password information. The .dockercfg will be
saved in the sandbox by the fetcher. When we call docker pull, we set the
$HOME env for the subprocess to point to the sandbox so that the docker
client can pick up that .dockercfg when pulling images.

Any comment/advice will be absolutely welcome!

Thanks,
Gilbert/Jie

Looking for shepherd (MESOS-4807)

[Yong Tang]

Hi All

I am looking for shepherd to help me on MESOS-4807. 

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

This issue is similar to MESOS-4806 as both of them tries to fixes issues that 
could parallelize the tests in mesos. Would appreciate if anyone could shepherd 
to help me on this issue (MESOS-4807).
Thanks a lotYong  

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

[Jörg Schad]

+1 (non-binding)
Ubuntu 14.04 + upgrade script from 27.2
Only encountered known issues.


On Tue, Mar 15, 2016 at 1:56 PM, Jörg Schad  wrote:

> I believe
> the ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand
> issue is already tracked here:
> https://issues.apache.org/jira/browse/MESOS-4810
> @zhitaio could you check whether this describes your issue (if so could
> you close the new issue as duplicate?). Thanks!
>
> On Tue, Mar 15, 2016 at 6:55 AM, Zhitao Li  wrote:
>
>> Filed https://issues.apache.org/jira/browse/MESOS-4946 to track.
>>
>> All "OsTest" passes under root on my machine.
>>
>> On Mon, Mar 14, 2016 at 6:30 PM, haosdent  wrote:
>>
>>> Maybe fill a ticket in https://issues.apache.org/jira/browse/MESOS
>>> would be more convenience for further discussion. By the way, could
>>> "OsTest.User" pass in your machine? It also call "os::getgid" during test.
>>>
>>> On Tue, Mar 15, 2016 at 6:57 AM, Zhitao Li 
>>> wrote:
>>>
 When running `sudo make check` on debian 8, I saw the following
 unaccounted test failure:

 [ FAILED ]
 ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand (1129
 ms)

 It seems to related to an error message with `Failed to change user to
 'root': Failed to getgid: unknown user`

 I've included verbose test log output at
 https://gist.github.com/zhitaoli/95436f4ea2df13c4b137.

 On Mon, Mar 14, 2016 at 2:59 PM, Daniel Osborne <
 daniel.osbo...@metaswitch.com> wrote:

> +1 (non-binding)
>
> Ran `sudo make check` on Centos 7. All tests passed.
>
> Also ran some runtime tests with unified containerizer launching
> docker images and regular mesos tasks, as well as some tasks using the
> docker containerizer. All working as expected
>
> Cheers,
> -Dan
>
> -Original Message-
> From: Vinod Kone [mailto:vinodk...@apache.org]
> Sent: Friday, March 11, 2016 12:46 PM
> To: dev ; user 
> Subject: [VOTE] Release Apache Mesos 0.28.0 (rc2)
>
> Hi all,
>
>
> Please vote on releasing the following candidate as Apache Mesos
> 0.28.0.
>
>
> 0.28.0 includes the following:
>
>
> 
>
> Release Notes - Mesos - Version 0.28.0
>
> 
>
> This release contains the following new features:
>
>   * [MESOS-4343] - A new cgroups isolator for enabling the net_cls
> subsystem in
>
> Linux. The cgroups/net_cls isolator allows operators to provide
> network
>
> performance isolation and network segmentation for containers
> within a Mesos
>
> cluster. To enable the cgroups/net_cls isolator, append
> `cgroups/net_cls` to
>
> the `--isolation` flag when starting the slave. Please refer to
>
> docs/mesos-containerizer.md for more details.
>
>
>   * [MESOS-4687] - The implementation of scalar resource values (e.g.,
> "2.5
>
> CPUs") has changed. Mesos now reliably supports resources with up
> to three
>
> decimal digits of precision (e.g., "2.501 CPUs"); resources with
> more than
>
> three decimal digits of precision will be rounded. Internally,
> resource math
>
> is now done using a fixed-point format that supports three decimal
> digits of
>
> precision, and then converted to/from floating point for input and
> output,
>
> respectively. Frameworks that do their own resource math and
> manipulate
>
> fractional resources may observe differences in roundoff error and
> numerical
>
> precision.
>
>
>   * [MESOS-4479] - Reserved resources can now optionally include
> "labels".
>
> Labels are a set of key-value pairs that can be used to associate
> metadata
>
> with a reserved resource. For example, frameworks can use this
> feature to
>
> distinguish between two reservations for the same role at the same
> agent
>
> that are intended for different purposes.
>
>
>   * [MESOS-2840] - **Experimental** support for container images in
> Mesos
>
> containerizer (a.k.a. Unified Containerizer). This allows
> frameworks to
>
> launch Docker/Appc containers using Mesos containerizer without
> relying on
>
> docker daemon (engine) or rkt. The isolation of the containers is
> done using
>
> isolators. Please refer to docs/container-image.md for currently
> supported
>
> features and limitations.
>
>
>   * [MESOS-4793] - **Experimental** support for v1 Executor HTTP API.
> This
>
> allows executors to send HTTP requests to the /api/v1/executor
> agent
>

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

[Jörg Schad]

I believe
the ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand
issue is already tracked here:
https://issues.apache.org/jira/browse/MESOS-4810
@zhitaio could you check whether this describes your issue (if so could you
close the new issue as duplicate?). Thanks!

On Tue, Mar 15, 2016 at 6:55 AM, Zhitao Li  wrote:

> Filed https://issues.apache.org/jira/browse/MESOS-4946 to track.
>
> All "OsTest" passes under root on my machine.
>
> On Mon, Mar 14, 2016 at 6:30 PM, haosdent  wrote:
>
>> Maybe fill a ticket in https://issues.apache.org/jira/browse/MESOS would
>> be more convenience for further discussion. By the way, could "OsTest.User"
>> pass in your machine? It also call "os::getgid" during test.
>>
>> On Tue, Mar 15, 2016 at 6:57 AM, Zhitao Li  wrote:
>>
>>> When running `sudo make check` on debian 8, I saw the following
>>> unaccounted test failure:
>>>
>>> [ FAILED ]
>>> ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand (1129
>>> ms)
>>>
>>> It seems to related to an error message with `Failed to change user to
>>> 'root': Failed to getgid: unknown user`
>>>
>>> I've included verbose test log output at
>>> https://gist.github.com/zhitaoli/95436f4ea2df13c4b137.
>>>
>>> On Mon, Mar 14, 2016 at 2:59 PM, Daniel Osborne <
>>> daniel.osbo...@metaswitch.com> wrote:
>>>
 +1 (non-binding)

 Ran `sudo make check` on Centos 7. All tests passed.

 Also ran some runtime tests with unified containerizer launching docker
 images and regular mesos tasks, as well as some tasks using the docker
 containerizer. All working as expected

 Cheers,
 -Dan

 -Original Message-
 From: Vinod Kone [mailto:vinodk...@apache.org]
 Sent: Friday, March 11, 2016 12:46 PM
 To: dev ; user 
 Subject: [VOTE] Release Apache Mesos 0.28.0 (rc2)

 Hi all,


 Please vote on releasing the following candidate as Apache Mesos 0.28.0.


 0.28.0 includes the following:


 

 Release Notes - Mesos - Version 0.28.0

 

 This release contains the following new features:

   * [MESOS-4343] - A new cgroups isolator for enabling the net_cls
 subsystem in

 Linux. The cgroups/net_cls isolator allows operators to provide
 network

 performance isolation and network segmentation for containers
 within a Mesos

 cluster. To enable the cgroups/net_cls isolator, append
 `cgroups/net_cls` to

 the `--isolation` flag when starting the slave. Please refer to

 docs/mesos-containerizer.md for more details.


   * [MESOS-4687] - The implementation of scalar resource values (e.g.,
 "2.5

 CPUs") has changed. Mesos now reliably supports resources with up
 to three

 decimal digits of precision (e.g., "2.501 CPUs"); resources with
 more than

 three decimal digits of precision will be rounded. Internally,
 resource math

 is now done using a fixed-point format that supports three decimal
 digits of

 precision, and then converted to/from floating point for input and
 output,

 respectively. Frameworks that do their own resource math and
 manipulate

 fractional resources may observe differences in roundoff error and
 numerical

 precision.


   * [MESOS-4479] - Reserved resources can now optionally include
 "labels".

 Labels are a set of key-value pairs that can be used to associate
 metadata

 with a reserved resource. For example, frameworks can use this
 feature to

 distinguish between two reservations for the same role at the same
 agent

 that are intended for different purposes.


   * [MESOS-2840] - **Experimental** support for container images in
 Mesos

 containerizer (a.k.a. Unified Containerizer). This allows
 frameworks to

 launch Docker/Appc containers using Mesos containerizer without
 relying on

 docker daemon (engine) or rkt. The isolation of the containers is
 done using

 isolators. Please refer to docs/container-image.md for currently
 supported

 features and limitations.


   * [MESOS-4793] - **Experimental** support for v1 Executor HTTP API.
 This

 allows executors to send HTTP requests to the /api/v1/executor agent

 endpoint without the need for an executor driver. Please refer to

 docs/executor-http-api.md for more details.


   * [MESOS-4370] Added support for service discovery of Docker
 containers that

 use Docker Remote API v1.21.


 Additional API Changes:

Re: Shepherd for MESOS-1757 Speed up the tests

[haosdent]

Thanks a lot!

On Tue, Mar 15, 2016 at 8:16 PM, Alex Rukletsov  wrote:

> Folks,
>
> I greatly appreciate the effort you have put into fixing all these issues.
> I don't think your patches will become stale, I would love to help you
> landing them once I have some cycles. If you don't find a shepherd this
> week, please ping me beginning next week.
>
> On Tue, Mar 15, 2016 at 3:29 AM, haosdent  wrote:
>
> > Hi, after @JianQiu and @Shuai Lin great jobs, most tickets in the
> > MESOS-1757
> > Speed up the tests 
> have
> > already reviewable.
> >
> > Because of @ben busy with other issues recently, I sent this email to
> seek
> > reviews and helps about the patches in this ticket. Any comments or
> reviews
> > are appreciated. What I worried about here is they are going to become
> > stale because they are already posted for a while. Thank you very much.
> >
> > --
> > Best Regards,
> > Haosdent Huang
> >
>



-- 
Best Regards,
Haosdent Huang

Re: Shepherd for MESOS-1757 Speed up the tests

[Alex Rukletsov]

Folks,

I greatly appreciate the effort you have put into fixing all these issues.
I don't think your patches will become stale, I would love to help you
landing them once I have some cycles. If you don't find a shepherd this
week, please ping me beginning next week.

On Tue, Mar 15, 2016 at 3:29 AM, haosdent  wrote:

> Hi, after @JianQiu and @Shuai Lin great jobs, most tickets in the
> MESOS-1757
> Speed up the tests  have
> already reviewable.
>
> Because of @ben busy with other issues recently, I sent this email to seek
> reviews and helps about the patches in this ticket. Any comments or reviews
> are appreciated. What I worried about here is they are going to become
> stale because they are already posted for a while. Thank you very much.
>
> --
> Best Regards,
> Haosdent Huang
>

Review request on Mesos-4930

[Zhou Z Xing]

   
 Hi,
   

   
 We submitted a patch on MESOS-4930 
https://issues.apache.org/jira/browse/MESOS-4930   
 which is reviewable at https://reviews.apache.org/r/44836/ 
   

   
 We'd highly appreciate it if someone could shepherd/review.
   

   
 Thanks!
   

   
 Jay and Tom from IBM CDL   
   

   




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