Here is a brief summary of proposed changes:
https://docs.google.com/document/d/1Fc_YhhV7fc4D9Xv6gJzpfooxbK4YWZcvzw6Bd3qVTL8
On Fri, Oct 2, 2015 at 1:47 PM, Bill Farner wrote:
> This matches what I was nudging towards. I think it offers what we want
> without taking on a large technical challeng
This matches what I was nudging towards. I think it offers what we want
without taking on a large technical challenge and placing restrictions on
the executor data blob.
On Friday, October 2, 2015, Maxim Khutornenko wrote:
> Thanks David. I agree pivoting this proposal around job update driven
Thanks David. I agree pivoting this proposal around job update driven
instructions would give us more incremental value for much less
effort. I have researched and evaluated various Java and JSON diff
libraries available under Apache license and could not find a
reasonable solution that would give
I'd like to propose an alternative - that we start off by having an API
endpoint which simply returns the JobUpdateInstructions that describes the
changes that would happen if a given JobUpdateRequest was applied.
There is a lot of value in having clients ask the scheduler to tell them
what is goi
I think it's fine to provide an 'enhanced' experience when the format is
JSON, but i don't think we should force that.
On Wed, Sep 16, 2015 at 10:22 AM, Maxim Khutornenko
wrote:
> The benefit of assuming a certain format is the richer experience we
> can give to our users. The *blob* may be too
The benefit of assuming a certain format is the richer experience we
can give to our users. The *blob* may be too large to make any sense
of it during diffing. I don't propose to enforce any schema though,
that would be too restrictive. I do however believe assuming JSON
format would be an acceptab
Isn't this data supposed to be any blob that transparently passes in to the
executor through mesos data blob. Why would we want to impose any sort of
format? It could be a binary blob. Executor writers should be able to move
between different schedulers/frameworks without any rework ideally. Thi
I'm a proponent of firming up our executor <-> scheduler contract. Since we
are going to get multiple executor support soon I think it would be nice if
we said that ExecutorConfig.data was JSON.
On Tue, Sep 15, 2015 at 10:47 AM, Maxim Khutornenko
wrote:
> | I hope this doesn't mean we would be r
| I hope this doesn't mean we would be returning a textual
representation of a diff
If we can make an assumption that executor data is always JSON, we can
deliver a much more specific answer by applying JSON diff tools.
Something like:
- "environment": "prod"
+ "environment": "test"
Otherwise, w
The 'blob'-iness of ExecutorConfig is intentional so that we can support
alternative executors. I'd hate for that to go away.
On Mon, Sep 14, 2015 at 8:56 PM, Jake Farrell wrote:
> This is one of the hoops encountered when using the Thrift api directly and
> not using the client, I'd love to se
This is one of the hoops encountered when using the Thrift api directly and
not using the client, I'd love to see ExecutorConfig.data move to a thrift
object and not be a string blob
-Jake
On Mon, Sep 14, 2015 at 9:28 PM, Bill Farner wrote:
> I like the idea of adding this API, but i don't see
I like the idea of adding this API, but i don't see why it requires us to
make assumptions about ExecutorConfig.data. I hope this doesn't mean we
would be returning a textual representation of a diff. Can you elaborate
on that?
On Mon, Sep 14, 2015 at 4:14 PM, Maxim Khutornenko wrote:
> Proble
Problem:
We currently don't have a good user experience around "aurora job
diff" command. The task configs are dumped as "prettified" JSON
strings and diffed with the system diff tool. Anyone who tried to use
it knows it can be very hard to read especially when it comes to
executor data deltas. Als
13 matches
Mail list logo
