> On Sept. 24, 2014, 6:28 p.m., David McLaughlin wrote:
> > What was the rationale for hiding update IDs from the user and making job 
> > key the parameter for update status? It's nice you can quickly see if a job 
> > key has an update in progress.. but what happens if you're wanting to see a 
> > recent deploy that is already finished or see further back?  
> > 
> > I think update list should return the update ids and update status should 
> > accept an update id. Well maybe not update status.. but update show or 
> > something? Something which is consistent with the job verbs would be great.

I was following the pattern that I saw in the API implementation. In early 
iterations, it exposed updated ids; in later ones, the IDs were removed from 
the user-level API. We don't use those identifiers for pausing or resuming an 
active update; why would we use them for checking on the status of an update? 
That would become a very awkward interface for users: start an update? use the 
jobkey. Pause an update? User the jobkey. Abort an update? Use the jobkey. 
Check the status of an update? Use some other identifier that you don't know 
without running another command.

I can certainly add the updateID to the list command, and add a command (or 
alternative parameter) for checking on a job by update-ID, but I don't think 
that making it the normal parameter to status is a good design for the 
command-line.


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26004/#review54466
-----------------------------------------------------------


On Sept. 24, 2014, 4:24 p.m., Mark Chu-Carroll wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26004/
> -----------------------------------------------------------
> 
> (Updated Sept. 24, 2014, 4:24 p.m.)
> 
> 
> Review request for Aurora, David McLaughlin and Zameer Manji.
> 
> 
> Bugs: aurora-742
>     https://issues.apache.org/jira/browse/aurora-742
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Add support for commands to query and display active updates being
> managed by the scheduler. Two commands are added:
> 
> * "aurora update list", which shows all active updates that are being 
> processed by the server.
> * "aurora update status", which shows detailed status information about an 
> update in-progress on the server.
> 
> 
> Diffs
> -----
> 
>   src/main/python/apache/aurora/client/cli/context.py 
> 102d20797816788361dfdac450aac9fb8e6fbc28 
>   src/main/python/apache/aurora/client/cli/options.py 
> c2d422ac2bc82fc387596e93040b49f722f8310f 
>   src/main/python/apache/aurora/client/cli/update.py 
> c6cb98fe6aa42310090167796c971856d3dc177f 
>   src/test/python/apache/aurora/client/cli/test_supdate.py 
> 4fb1623e497b9741ae2a350deb20030dd4036506 
>   src/test/python/apache/aurora/client/cli/util.py 
> a50b83c571390374975accf75e31f392dbdaaa04 
> 
> Diff: https://reviews.apache.org/r/26004/diff/
> 
> 
> Testing
> -------
> 
> Added new unit tests; all tests pass.
> 
> 
> Thanks,
> 
> Mark Chu-Carroll
> 
>

Reply via email to