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
