> On Dec. 2, 2016, 6:26 p.m., Alejandro Fernandez wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/CalculatedStatus.java,
> >  line 57
> > <https://reviews.apache.org/r/54264/diff/3/?file=1574705#file1574705line57>
> >
> >     I think this will work most of the time. However, if users are deleting 
> > x records out of the host_role_command table, then there's still a chance 
> > that an RU/EU will still have tasks that aren't deleted, and hence the 
> > upgrade will still show up as PENDING.
> >     
> >     In my opinion, we need a better way of deleting old records. What do 
> > you think?
> >     
> >     It would be ideal if the user can be prompted to delete data older than 
> > x days. If an EU/RU falls in that category, then we find the requestIDs and 
> > then delete all tasks that belong to those requestIDs. This way, there is 
> > no "partial deletion" of data, which can be problematic.
> 
> Nate Cole wrote:
>     Seems to me that people shouldn't be removing records out of the DB that 
> can orphan requests like this.  We have a way to clean records, it just 
> doesn't look like it's implemented for R/S/T (only for Alerts for some 
> reason).
>     
>     We can even make it such that only COMPLETED requests are fully purged.  
> Who cares about the history that all DN were successfully restarted three 
> months ago?

I believe we have a PreCheck that finds the last Upgrade and makes sure that it 
completed (not sure if it checks the request status or the last 3 tasks during 
Finalize).
Either way, I don't think users should leave orphan records. Our story for 
cleaning up history shouldn't be through manually deleting records. I would 
prefer if this could be done through an API and eventually UI.


- Alejandro


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


On Dec. 2, 2016, 2:43 p.m., Jonathan Hurley wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54264/
> -----------------------------------------------------------
> 
> (Updated Dec. 2, 2016, 2:43 p.m.)
> 
> 
> Review request for Ambari, Nate Cole, Robert Levas, Robert Nettleton, and 
> Sebastian Toader.
> 
> 
> Bugs: AMBARI-19055
>     https://issues.apache.org/jira/browse/AMBARI-19055
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> It may be necessary to remove entries from the {{host_role_command}} table if 
> the size of the table has grown excessively large in order to reduce the 
> query times for "IN_PROGRESS" requests.
> 
> However, if you remove all tasks for an upgrade, but you leave the stages, 
> request, and upgrade items, the upgrade will appear as though it is now 
> {{PENDING}}.
> 
> {noformat:title=Before Removal}
> {
>   "href": "http://localhost:8080/api/v1/clusters/c1/upgrades/12";,
>   "Upgrade": {
>     ...
>     "request_status": "COMPLETED",
>     "skip_failures": false,
>     "skip_service_check_failures": false,
>     "start_time": 1480517560950,
>     "suspended": false,
>     "to_version": "2.5.2.0-67",
>     "type": "INTERNAL_REQUEST",
>     "upgrade_type": "NON_ROLLING"
>   },
>   "upgrade_groups": [
>   ...
> {noformat}
> 
> {noformat:title=After Removal}
> {
>   "href": "http://localhost:8080/api/v1/clusters/c1/upgrades/12";,
>   "Upgrade": {
>     ...
>     "request_status": "PENDING",
>     "skip_failures": false,
>     "skip_service_check_failures": false,
>     "start_time": 1480517560950,
>     "suspended": false,
>     "to_version": "2.5.2.0-67",
>     "type": "INTERNAL_REQUEST",
>     "upgrade_type": "NON_ROLLING"
>   },
>   "upgrade_groups": [
>   ...
> {noformat}
> 
> The actual request is showing as {{COMPLETED}} correctly:
> {noformat}
> {
>   "href": "http://localhost:8080/api/v1/clusters/c1/requests/12";,
>   "Requests": {
>     "aborted_task_count": 0,
>     "cluster_name": "c1",
>     "completed_task_count": 0,
>     "create_time": 1480517560897,
>     "end_time": 1480517643350,
>     "exclusive": false,
>     "failed_task_count": 0,
>     "id": 12,
>     "inputs": null,
>     "operation_level": null,
>     "progress_percent": 100,
>     "queued_task_count": 0,
>     "request_context": "Upgrading to 2.5.2.0-67",
>     "request_schedule": null,
>     "request_status": "COMPLETED",
>     "resource_filters": [],
>     "start_time": 1480517560950,
>     "task_count": 0,
>     "timed_out_task_count": 0,
>     "type": "INTERNAL_REQUEST"
>   },
>   "tasks": [],
>   ...
> {noformat}
> 
> STR:
> - Perform a simple upgrade of a ZK-only cluster
> - Find out the ID of the upgrade request (say its 12)
> - Remove tasks
> {code}
> DELETE FROM execution_command WHERE task_id IN (SELECT task_id FROM 
> host_role_command WHERE request_id = 12)
> 
> DELETE FROM host_role_command WHERE request_id = 12
> {code}
> 
> 
> Diffs
> -----
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/CalculatedStatus.java
>  3a86aef 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RequestResourceProvider.java
>  8c1bc57 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StageResourceProvider.java
>  59dd9d9 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/CalculatedStatusTest.java
>  6f592cd 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/RequestResourceProviderTest.java
>  5dfc74d 
> 
> Diff: https://reviews.apache.org/r/54264/diff/
> 
> 
> Testing
> -------
> 
> Tests run: 4785, Failures: 0, Errors: 0, Skipped: 37
> 
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Total time: 26:38 min
> [INFO] Finished at: 2016-12-01T16:51:11-05:00
> [INFO] Final Memory: 57M/704M
> [INFO] 
> ------------------------------------------------------------------------
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

Reply via email to