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
>
