Mailing-List: contact dev-help@aurora.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aurora.incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of kburg@foursquare.com
 designates 209.85.216.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABkJX4L2e4zxxyESeDDKjjgiA3rJynS4kSa4s_dOKd5q45am2A@mail.gmail.com>
References: 
 <CAD99eHOgt58es4YkUk55y2Aq8=r9_H-OqAEFNLxWenwBMjEJFw@mail.gmail.com>
	<CAFTdr0B=Q6bWS0FqBetXVKDhgm0Q=9=Jiy3RH-HA99iCoBNuGw@mail.gmail.com>
	<CABkJX4L2e4zxxyESeDDKjjgiA3rJynS4kSa4s_dOKd5q45am2A@mail.gmail.com>
Date: Mon, 14 Jul 2014 11:26:35 -0700
Message-ID: 
 <CAD99eHNRn1G50QxZgAvBhFdnkyDc2OMu==4PYu_Dhg4rkKfK2Q@mail.gmail.com>
Subject: Re: Task Constraints
From: Kevin Burg <kburg@foursquare.com>
To: Josh Adams <josh@foursquare.com>
Cc: Brian Wickman <wickman@apache.org>, dev@aurora.incubator.apache.org
Content-Type: multipart/alternative; boundary=047d7bdc96b060042b04fe2b6e83

--047d7bdc96b060042b04fe2b6e83
Content-Type: text/plain; charset=UTF-8

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 <josh@foursquare.com> wrote:

> Thanks Brian. Kevin should have some followup questions shortly.
>
> Josh
>
>
> On Mon, Jul 14, 2014 at 10:37 AM, Brian Wickman <wickman@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 <kburg@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
>

--047d7bdc96b060042b04fe2b6e83--