I've taken on the ticket and have a fix posted, hopefully to be committed
today.
-=Bill
On Wed, Jul 16, 2014 at 12:21 PM, Josh Adams wrote:
> +Leo Kim who is looking at the compiler error with us.
>
>
> On Wed, Jul 16, 2014 at 8:25 AM, Kevin Burg wrote:
>
> > The idea with the fix is to read
+Leo Kim who is looking at the compiler error with us.
On Wed, Jul 16, 2014 at 8:25 AM, Kevin Burg wrote:
> The idea with the fix is to read the slave's attributes right off the
> offer rather than going into 'AttributeStore' and keying on the slave's
> name. The slave's resources are read off
The idea with the fix is to read the slave's attributes right off the offer
rather than going into 'AttributeStore' and keying on the slave's name. The
slave's resources are read off the offer in this way, so I don't see why it
can't be done with attributes as well.
Someone who understands all the
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.
Removing the meta directory does not fix the issue. Upon further
inspection, the scheduler seems to be using very old slave ids. These slave
ids aren't even in "mesos/slave/workdir/slaves" anymore. I should add that
the "/offers" endpoint on the scheduler shows all the up to date
information includ
However, the slave should be failing and logging this (rather than silently
working with old attributes). If you find otherwise, you should file a bug
against mesos.
On Monday, July 14, 2014, Josh Adams wrote:
> Ah, makes sense. We'll try that. Thanks for clarifying this Kevin.
>
> Josh
>
>
> O
Ah, makes sense. We'll try that. Thanks for clarifying this Kevin.
Josh
On Mon, Jul 14, 2014 at 11:30 AM, Kevin Sweeney 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 th
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 wil
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 wrote:
> Thanks Brian. Kevin should hav
Thanks Brian. Kevin should have some followup questions shortly.
Josh
On Mon, Jul 14, 2014 at 10:37 AM, Brian Wickman 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 slav
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 attri
11 matches
Mail list logo
