Details
Description
Currently services that fail provisioning may continue to attempt provisioning every time the cron runs, indefinitely.
A setting should be added "Halt Automatic Provision After Attempts" which will stop provision attempts on a service after X attempts have failed. The setting should be a drop down containing
- Never
- 1
- 2
- ...
- 30
In order to track number of failed attempts we should add a new status to the log_services table called provision_failed. Make sure that adding this status does not mess up any of the current suspension/unsuspension behavior that depends on this log.
In addition, a new email template service_provision_halted should be created with the name Service Provisioning Halted and the subject Automatic Provisioning Halted for Service -
{service.name}This email should be sent to subscribed admins when provisioning is halted on a service. This email should appear under the "Email Subscription Notices" section on the My Info and Staff Group pages.
For additional visibility, we may want to add a note to the clients dashboard, similar the the due invoices notice, that tells them which services, if any, have halted provisioning.
Issue Links
- relates to
-
CORE-901
Add service action backoff after failure
-
- Closed
-
Activity
If we do this task it would make at least part of CORE-901 unnecessary
| Story Points | 5 |
| Fix Version/s | Sponsored [ 11113 ] | |
| Fix Version/s | 4.7.1 [ 11126 ] |
| Description |
Sometimes services fail to provision, and will continue to do so until something is changed manually. To prevent attempts to provision these every 5 minutes until forever, we should add a setting "Stop Automatic Provisions After Attempts" or some such thing. Then we add a drop down of how many attempts to make before suspending automatic provisions for a service. Probably 1-30 or no limit.
In order to do this we will either need to create a new log table or adapt the current log_services table to support service provision failures. We also need to make sure that users know that provisioning has been suspended. Maybe an email to the admin? Another log page? A notice message on the user profile? |
Currently services that fail provisioning may continue to attempt provisioning every time the cron runs, indefinitely.
A setting should be added "Halt Automatic Provision After Attempts" which will stop provision attempts on a service after X attempts have failed. The setting should be a drop down containing * Never * 1 * 2 * ... * 30 In order to track number of failed attempts we should add a new status to the log_services table called provision_failed. Make sure that adding this status does not mess up any of the current suspension/unsuspension behavior that depends on this log. In addition, a new email template service_provision_halted should be created with the name "Service Provisioning Halted" and the subject "Automatic Provisioning Halted for Service - {service.name}". This email should be sent to subscribed admins when provisioning is halted on a service. This email should appear under the "Email Subscription Notices" section on the My Info and Staff Group pages. For additional visibility, we may want to add a note to the clients dashboard, similar the the due invoices notice, that tells them which services, if any, have halted provisioning. |
| Description |
Currently services that fail provisioning may continue to attempt provisioning every time the cron runs, indefinitely.
A setting should be added "Halt Automatic Provision After Attempts" which will stop provision attempts on a service after X attempts have failed. The setting should be a drop down containing * Never * 1 * 2 * ... * 30 In order to track number of failed attempts we should add a new status to the log_services table called provision_failed. Make sure that adding this status does not mess up any of the current suspension/unsuspension behavior that depends on this log. In addition, a new email template service_provision_halted should be created with the name "Service Provisioning Halted" and the subject "Automatic Provisioning Halted for Service - {service.name}". This email should be sent to subscribed admins when provisioning is halted on a service. This email should appear under the "Email Subscription Notices" section on the My Info and Staff Group pages. For additional visibility, we may want to add a note to the clients dashboard, similar the the due invoices notice, that tells them which services, if any, have halted provisioning. |
Currently services that fail provisioning may continue to attempt provisioning every time the cron runs, indefinitely.
A setting should be added "Halt Automatic Provision After Attempts" which will stop provision attempts on a service after X attempts have failed. The setting should be a drop down containing * Never * 1 * 2 * ... * 30 In order to track number of failed attempts we should add a new status to the log_services table called provision_failed. Make sure that adding this status does not mess up any of the current suspension/unsuspension behavior that depends on this log. In addition, a new email template service_provision_halted should be created with the name Service Provisioning Halted and the subject Automatic Provisioning Halted for Service - {service.name}. This email should be sent to subscribed admins when provisioning is halted on a service. This email should appear under the "Email Subscription Notices" section on the My Info and Staff Group pages. For additional visibility, we may want to add a note to the clients dashboard, similar the the due invoices notice, that tells them which services, if any, have halted provisioning. |
| Description |
Currently services that fail provisioning may continue to attempt provisioning every time the cron runs, indefinitely.
A setting should be added "Halt Automatic Provision After Attempts" which will stop provision attempts on a service after X attempts have failed. The setting should be a drop down containing * Never * 1 * 2 * ... * 30 In order to track number of failed attempts we should add a new status to the log_services table called provision_failed. Make sure that adding this status does not mess up any of the current suspension/unsuspension behavior that depends on this log. In addition, a new email template service_provision_halted should be created with the name Service Provisioning Halted and the subject Automatic Provisioning Halted for Service - {service.name}. This email should be sent to subscribed admins when provisioning is halted on a service. This email should appear under the "Email Subscription Notices" section on the My Info and Staff Group pages. For additional visibility, we may want to add a note to the clients dashboard, similar the the due invoices notice, that tells them which services, if any, have halted provisioning. |
Currently services that fail provisioning may continue to attempt provisioning every time the cron runs, indefinitely.
A setting should be added "Halt Automatic Provision After Attempts" which will stop provision attempts on a service after X attempts have failed. The setting should be a drop down containing * Never * 1 * 2 * ... * 30 In order to track number of failed attempts we should add a new status to the log_services table called provision_failed. Make sure that adding this status does not mess up any of the current suspension/unsuspension behavior that depends on this log. In addition, a new email template service_provision_halted should be created with the name Service Provisioning Halted and the subject Automatic Provisioning Halted for Service - {service.name} This email should be sent to subscribed admins when provisioning is halted on a service. This email should appear under the "Email Subscription Notices" section on the My Info and Staff Group pages. For additional visibility, we may want to add a note to the clients dashboard, similar the the due invoices notice, that tells them which services, if any, have halted provisioning. |
| Rank | Ranked higher |
Tyson Phillips (Inactive)
made changes -
| Rank | Ranked higher |
| Rank | Ranked higher |
| Rank | Ranked lower |
Instead of using log_services we should generalize service_invoices
This task will work similar to the service renewal queue. We'll rename Tools > Renewal Queue, so that it works for both new and renewing services, and we will show whether it's a new or renewing service in the queue.
Paul Phillips
added a comment - This task will work similar to the service renewal queue. We'll rename Tools > Renewal Queue, so that it works for both new and renewing services, and we will show whether it's a new or renewing service in the queue. Paul Phillips
made changes -
| Fix Version/s | 5.11.0-b1 [ 11908 ] |
Paul Phillips
made changes -
| Rank | Ranked higher |
Paul Phillips
made changes -
| Rank | Ranked lower |
| Sprint | 5.11.0 Sprint 2 [ 196 ] |
| Rank | Ranked lower |
| Assignee | Jonathan Reissmueller [ jonathan ] |
| Sprint | 5.11.0 Sprint 2 [ 196 ] | 5.11.0 Sprint 3 [ 202 ] |
| Rank | Ranked higher |
| Rank | Ranked lower |
| Rank | Ranked higher |
| Assignee | Abdy Franco [ abdy ] |
| Remaining Estimate | 5 minutes [ 300 ] | 0 minutes [ 0 ] |
| Time Spent | 4 hours, 3 minutes [ 14580 ] | |
| Worklog Id | 17361 [ 17361 ] |
| Time Spent | 4 hours, 3 minutes [ 14580 ] | 1 day, 3 hours, 56 minutes [ 42960 ] |
| Worklog Id | 17362 [ 17362 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Time Spent | 1 day, 3 hours, 56 minutes [ 42960 ] | 2 days, 3 hours, 40 minutes [ 70800 ] |
| Worklog Id | 17363 [ 17363 ] |
| Time Spent | 2 days, 3 hours, 40 minutes [ 70800 ] | 3 days, 3 hours, 42 minutes [ 99720 ] |
| Worklog Id | 17364 [ 17364 ] |
| Time Spent | 3 days, 3 hours, 42 minutes [ 99720 ] | 3 days, 5 hours, 40 minutes [ 106800 ] |
| Worklog Id | 17366 [ 17366 ] |
| Time Spent | 3 days, 5 hours, 40 minutes [ 106800 ] | 4 days, 5 hours, 38 minutes [ 135480 ] |
| Worklog Id | 17374 [ 17374 ] |
| Time Spent | 4 days, 5 hours, 38 minutes [ 135480 ] | 1 week, 5 hours, 42 minutes [ 164520 ] |
| Worklog Id | 17375 [ 17375 ] |
| Time Spent | 1 week, 5 hours, 42 minutes [ 164520 ] | 1 week, 1 day, 5 hours, 44 minutes [ 193440 ] |
| Worklog Id | 17376 [ 17376 ] |
| Time Spent | 1 week, 1 day, 5 hours, 44 minutes [ 193440 ] | 1 week, 2 days, 5 hours, 41 minutes [ 222060 ] |
| Worklog Id | 17377 [ 17377 ] |
| Time Spent | 1 week, 2 days, 5 hours, 41 minutes [ 222060 ] | 1 week, 3 days, 5 hours, 42 minutes [ 250920 ] |
| Worklog Id | 17378 [ 17378 ] |
| Status | In Progress [ 3 ] | In Review [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Sprint | 5.11.0 Sprint 3 [ 202 ] | 5.11.0 Sprint 3, 5.11.0 Sprint 4 [ 202, 203 ] |
| Rank | Ranked higher |
| Sprint | 5.11.0 Sprint 3, 5.11.0 Sprint 4 [ 202, 203 ] | 5.11.0 Sprint 3, 5.11.0 Sprint 4, 5.11.0 Sprint 5 [ 202, 203, 204 ] |
| Rank | Ranked higher |
| Time Spent | 1 week, 3 days, 5 hours, 42 minutes [ 250920 ] | 1 week, 3 days, 7 hours, 14 minutes [ 256440 ] |
| Worklog Id | 17461 [ 17461 ] |
| Time Spent | 1 week, 3 days, 7 hours, 14 minutes [ 256440 ] | 1 week, 4 days, 6 hours, 36 minutes [ 282960 ] |
| Worklog Id | 17463 [ 17463 ] |
| Status | In Review [ 5 ] | Closed [ 6 ] |
We also may want to do this sort of thing for suspension/unsuspension/cancellation and not just for service creation