> On July 31, 2014, 11:13 p.m., Bill Farner wrote:
> > src/main/thrift/org/apache/aurora/gen/api.thrift, line 546
> > <https://reviews.apache.org/r/24116/diff/3/?file=647049#file647049line546>
> >
> > I find the latest revision of the structs a bit tough to comprehend.
> > How about this tweak:
> >
> > struct JobUpdateRequest {
> > // fields currently in UpdateSettings and UpdateConfiguration
> > }
> >
> > // the high-level view of what an update intended to do, and its
> > current status
> > struct JobUpdate {
> > 1: string id
> > 2: JobKey job
> > 3: TaskConfig config
> > 4: i32 instances
> > 5: UpdateStatus status
> > 6: i64 startTimestampMs
> > 7: i64 endTimestampMs
> > }
> >
> > enum InstanceUpdateAction {
> > ROLLED_FORWARD,
> > ROLLED_BACK,
> > ADDED,
> > REMOVED
> > }
> >
> > // the individual actions taken as part of an update
> > struct InstanceUpdateEvent {
> > 1: i32 instance
> > 2: InstanceUpdateAction action
> > 3: i64 timestampMs
> > }
> >
> > These two structs would be fetched via two separate API calls.
>
> Maxim Khutornenko wrote:
> How does JobUpdate fit with the getUpdates() API? Do you propose we
> return JobUpdate + map<i32, InstanceUpdateEvent> with it?
>
> I am not sure I like the fact that we are mixing immutable and mutable
> data within the same return struct. This would mean we always return
> TaskConfig even when it's not really needed.
>
> I'd rather go with Event-only getUpdates() API and have something like
> getUpdateDetails(string id) that would return JobUpdate with immutable-only
> data. This approach is more like the current diff + a new API to return
> JobUpdate only.
>
> Bill Farner wrote:
> In the above arrangement, getUpdates() would return set<JobUpdate>,
> another API would return the events associated with a specific update.
> (That's what i meant by "These two structs would be fetched via two separate
> API calls.")
>
> Maxim Khutornenko wrote:
> In that case, the getUpdates(UpdateQuery) would return a bunch of quite
> heavy JobUpdate objects without any need for their TaskConfigs. This would
> make a query across cluster quite an expensive one.
>
> Why not make getUpdates() return event-only data and another API fetch
> heavy stuff when it's really needed? I think we are on the same page wrt 2
> APIs, I just think the default (getUpdates) API should not include
> TaskConfigs with it.
Instead of my original JobUpdate, how about this:
struct JobUpdate {
1: string id
2: JobKey job
3: UpdateStatus status
4: i64 endTimestampMs
}
InstanceUpdateAction, InstanceUpdateEvent,
s/JobUpdateRequest/JobUpdateConfiguration/ as above
Then 3 API methods:
- getJobUpdates(JobUpdateQuery query)
- getJobUpdateConfiguration(string id)
- getJobUpdateEvents(string id)
- Bill
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24116/#review49301
-----------------------------------------------------------
On July 31, 2014, 6:37 p.m., Maxim Khutornenko wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24116/
> -----------------------------------------------------------
>
> (Updated July 31, 2014, 6:37 p.m.)
>
>
> Review request for Aurora, David McLaughlin and Bill Farner.
>
>
> Bugs: AURORA-611
> https://issues.apache.org/jira/browse/AURORA-611
>
>
> Repository: aurora
>
>
> Description
> -------
>
> First stab at update APIs.
>
>
> Diffs
> -----
>
>
> src/main/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterface.java
> 12de5a3e9e3aae217b30c385e2d7ec7b43863ae2
> src/main/thrift/org/apache/aurora/gen/api.thrift
> 54b8985971719247a5d42d8676075a51045bbb92
> src/test/java/org/apache/aurora/scheduler/thrift/aop/ForwardingThrift.java
> 2ea4a9ba0a1ea81fea5c4f5203457aa79ae67c10
>
> Diff: https://reviews.apache.org/r/24116/diff/
>
>
> Testing
> -------
>
> gradle build
>
>
> Thanks,
>
> Maxim Khutornenko
>
>
