Mailing-List: contact dev-help@aurora.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aurora.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAGRA8uP31f0Ogu_mFWD47XitT=4Tdp_JYTOZSDRhzPt+Lb_GCA@mail.gmail.com>
References: 
 <CAOTkfX6C2-BD=vN9PSNbmWntZ2CLax23PmfG8L5m75rRPOZthw@mail.gmail.com>
	<CAOOJoEw2Dz4fDtChRFpQ2wMYhwhWn=kw1_4jH542nz1fMY9a3A@mail.gmail.com>
	<CAK7Zj13dBsB4ZGKKJ44f-SGhHnWOQj6BKGPq4_PJar3N40VXaQ@mail.gmail.com>
	<CAMnduq_XLDA2htSts4SiTmaBpx1kM-TkskST_Z23HOuYe2GzFw@mail.gmail.com>
	<E1F9360E-F851-473C-99F3-29FD9EA0C6DB@gmail.com>
	<CACZ0aJVEotSUpUv-DTMuwMJ0a_mrbfdD778DDhE4xcvQo6VRig@mail.gmail.com>
	<CAOTkfX7NXbEkPcncRj0PXjn_e6xN4-hD9yBF9uFEXOv4j9u+NQ@mail.gmail.com>
	<CACZ0aJUH0t2ezCaOz6Xx5YhiDXiTBZLca_y6OR+1rupsnOWV4g@mail.gmail.com>
	<CAGRA8uP31f0Ogu_mFWD47XitT=4Tdp_JYTOZSDRhzPt+Lb_GCA@mail.gmail.com>
Date: Fri, 3 Apr 2015 16:14:34 -0700
Message-ID: 
 <CAGRA8uPyNdSMkO6cLatpY=9yzNNOuAeB6DPo8vL62uJugZxsXQ@mail.gmail.com>
Subject: Re: Deprecating "restart_theshold" setting
From: Bill Farner <wfarner@apache.org>
To: "dev@aurora.apache.org" <dev@aurora.apache.org>
Content-Type: multipart/alternative; boundary=001a11350fd28fa9430512da1cf2

--001a11350fd28fa9430512da1cf2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I've prepared a minimal patch to remove this behavior from the scheduler:
https://reviews.apache.org/r/32840/

-=3DBill

On Fri, Apr 3, 2015 at 3:50 PM, Bill Farner <wfarner@apache.org> wrote:

> The bright side is that you (the cluster administrator) can buffer for
> this in only the global task timeout setting, and it doesn't have to leak
> into everyone's update configurations.
>
> -=3DBill
>
> On Fri, Apr 3, 2015 at 1:06 PM, Steve Niemitz <steve@tellapart.com> wrote=
:
>
>> oh hm, I thought it started as soon as the task was launched, if it
>> already
>> starts the timer at RUNNING never mind then :)
>>
>> On Fri, Apr 3, 2015 at 12:18 PM, Maxim Khutornenko <maxim@apache.org>
>> wrote:
>>
>> > >Does this also include making the timer for "initial_interval_secs"
>> start
>> > >when the task enters RUNNING?
>> >
>> > Did you rather mean STARTING as in AURORA-894? The
>> > "initial_interval_sec" currently starts in RUNNING and AURORA-894
>> > suggests moving it into STARTING.
>> >
>> > On Fri, Apr 3, 2015 at 12:02 PM, Steve Niemitz <steve@tellapart.com>
>> > wrote:
>> > > +100.  This is particularly annoying with docker tasks, as the task
>> > doesn't
>> > > enter running until the pull completes.
>> > >
>> > > Does this also include making the timer for "initial_interval_secs"
>> start
>> > > when the task enters RUNNING?
>> > >
>> > > On Fri, Apr 3, 2015 at 11:57 AM, Joseph Smith <yasumoto7@gmail.com>
>> > wrote:
>> > >
>> > >> Also a +1, users can=E2=80=99t do anything to modify this other tha=
n just
>> > increase
>> > >> this threshold in case we don=E2=80=99t do the right thing.
>> > >>
>> > >> > On Apr 2, 2015, at 4:58 PM, Joshua Cohen <jcohen@twopensource.com=
>
>> > >> wrote:
>> > >> >
>> > >> > +1
>> > >> >
>> > >> > On Thu, Apr 2, 2015 at 2:34 PM, Zameer Manji <zmanji@apache.org>
>> > wrote:
>> > >> >
>> > >> >> +1
>> > >> >>
>> > >> >> I think we should be very careful in the future to ensure user
>> > provided
>> > >> >> timeouts do not cover state transitions outside of their control=
.
>> > >> >>
>> > >> >> On Thu, Apr 2, 2015 at 2:29 PM, David McLaughlin <
>> > david@dmclaughlin.com
>> > >> >
>> > >> >> wrote:
>> > >> >>
>> > >> >>> +1 to the proposal.
>> > >> >>>
>> > >> >>> On Thu, Apr 2, 2015 at 2:09 PM, Maxim Khutornenko <
>> maxim@apache.org
>> > >
>> > >> >>> wrote:
>> > >> >>>
>> > >> >>>> We are proposing to drop the UpdateConfig restart_threshold
>> setting
>> > >> >>>> due to not delivering much end user value. Please, take a
>> moment to
>> > >> >>>> read through https://issues.apache.org/jira/browse/AURORA-1240
>> and
>> > >> >>>> reply back if you have any doubts.
>> > >> >>>>
>> > >> >>>> Thanks,
>> > >> >>>> Maxim
>> > >> >>>>
>> > >> >>>
>> > >> >>> --
>> > >> >>> Zameer Manji
>> > >> >>>
>> > >> >>>
>> > >> >>
>> > >>
>> > >>
>> >
>>
>
>

--001a11350fd28fa9430512da1cf2--