Hi there,

Given that we would need to disrupt running jobs to add constraints in the
future we are blocking on https://issues.apache.org/jira/browse/AURORA-582
before we can push any of our services on to Aurora in production.

Kevin Burg attempted to resolve the related bug
https://issues.apache.org/jira/browse/AURORA-328 by making some changes
here:
https://github.com/foursquare/incubator-aurora/commit/b1962fad3fe9ef76954fa107abed25d78b809331
but we seem to be getting a type mismatch when compiling the code.

Any help and/or info on the bugfix progress would be much appreciated.
Aside from AURORA-582 we are ready to roll (pun intended!)

Best,
Josh


On Mon, Jul 14, 2014 at 11:42 AM, Josh Adams <j...@foursquare.com> wrote:

> Ah, makes sense. We'll try that. Thanks for clarifying this Kevin.
>
> Josh
>
>
> On Mon, Jul 14, 2014 at 11:30 AM, Kevin Sweeney <kevi...@apache.org>
> wrote:
>
>> Slaves persist their attributes (including attributes) across restarts
>> due to slave recovery (that's what allows you to upgrade mesos in-place
>> without killing the tasks they're managing). Unfortunately to change
>> attributes you need to remove persisted slave metadata (the "meta"
>> directory). This will kill all of a slave's underlying tasks but the newly
>> registered slave should have the correct attributes.
>>
>>
>> On Mon, Jul 14, 2014 at 11:26 AM, Kevin Burg <kb...@foursquare.com>
>> wrote:
>>
>>> I've confirmed by looking at that endpoint that new attributes are not
>>> being picked up and modified attributes are retaining their old values.
>>> This is after restarting both the slaves and the scheduler process.
>>>
>>>
>>> On Mon, Jul 14, 2014 at 11:09 AM, Josh Adams <j...@foursquare.com>
>>> wrote:
>>>
>>> > Thanks Brian. Kevin should have some followup questions shortly.
>>> >
>>> > Josh
>>> >
>>> >
>>> > On Mon, Jul 14, 2014 at 10:37 AM, Brian Wickman <wick...@apache.org>
>>> > wrote:
>>> >
>>> >> host/rack should not be treated specially.
>>> >>
>>> >> If you go to the "/slaves" endpoint on the scheduler UI, what does it
>>> >> report as attributes being exported by your slaves?  You might want to
>>> >> validate there that the "staging" attribute got picked up properly.
>>>  If
>>> >> it's not getting picked up (e.g. the attributes are getting cached
>>> >> incorrectly by the scheduler?) then you should file an issue.
>>> >>
>>> >>
>>> >> On Fri, Jul 11, 2014 at 5:24 PM, Kevin Burg <kb...@foursquare.com>
>>> wrote:
>>> >>
>>> >>> Hi,
>>> >>>
>>> >>> I'm having trouble getting the task constraint resolver worker with
>>> >>> attributes other than 'host' and 'rack.' Are arbitrary attribute
>>> keys in
>>> >>> the mesos slaves supported currently?
>>> >>>
>>> >>> Here is the setup.
>>> >>>
>>> >>> The slaves are configured to run with
>>> >>> `--attributes=host:<host>;rack:<rack>;staging:true`
>>> >>>
>>> >>> (I've also tried this with staging:1, and staging:foo)
>>> >>>
>>> >>> The constraint generated from the .aurora config looks like the
>>> following
>>> >>> Constraint(name:staging, constraint:<TaskConstraint
>>> >>> value:ValueConstraint(negated:false, values:[true])>)
>>> >>>
>>> >>> The schedule request then gets vetoed with the following veto object:
>>> >>> Veto{reason=Constraint not satisfied: staging, score=1000,
>>> >>> valueMismatch=true}]
>>> >>>
>>> >>> The constraints generated for 'host' and 'rack' look identical
>>> except for
>>> >>> the different name of course. I've even tried bouncing every mesos
>>> and
>>> >>> aurora process on the machine to see if maybe stale attributes were
>>> being
>>> >>> assigned to the slaves. All the offers being made to the master look
>>> >>> correct though, which leads me to believe that the constraint solver
>>> just
>>> >>> doesn't work for arbitrary attributes.
>>> >>>
>>> >>> We would appreciate any help you can offer.
>>> >>>
>>> >>> Thanks,
>>> >>> Kevin
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > ===============
>>> > josh adams
>>> > production engineer
>>> > foursquare
>>> >
>>> > (gv) 415-830-4106
>>> > ===============
>>> > foursquare.com/jobs
>>> >
>>>
>>
>>
>
>
> --
> ===============
> josh adams
> production engineer
> foursquare
>
> (gv) 415-830-4106
> ===============
> foursquare.com/jobs
>



-- 
===============
josh adams
production engineer
foursquare

(gv) 415-830-4106
===============
foursquare.com/jobs

Reply via email to