> On Sept. 24, 2014, 10: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.
> 
> Mark Chu-Carroll wrote:
>     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 Chu-Carroll wrote:
>     ping?

Can we add updateID to the list command? Then this looks ready to ship.


- David


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


On Sept. 24, 2014, 8: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, 8: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