Uploaded image for project: 'Blesta Core'
  1. Blesta Core
  2. CORE-3274

Stop Service Provision Attempts After x Failures

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Sponsored, 5.11.0-b1
    • Component/s: None
    • Labels:
      None

      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

          Activity

          jonathan Jonathan Reissmueller created issue -
          jonathan Jonathan Reissmueller made changes -
          Field Original Value New Value
          Link This issue relates to CORE-901 [ CORE-901 ]
          jonathan Jonathan Reissmueller made changes -
          Story Points 5
          jonathan Jonathan Reissmueller made changes -
          Fix Version/s Sponsored [ 11113 ]
          Fix Version/s 4.7.1 [ 11126 ]
          jonathan Jonathan Reissmueller made changes -
          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.

          jonathan Jonathan Reissmueller made changes -
          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.

          jonathan Jonathan Reissmueller made changes -
          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.

          jonathan Jonathan Reissmueller made changes -
          Rank Ranked higher
          tyson Tyson Phillips (Inactive) made changes -
          Rank Ranked higher
          jonathan Jonathan Reissmueller made changes -
          Rank Ranked higher
          jonathan Jonathan Reissmueller made changes -
          Rank Ranked lower
          admin Paul Phillips made changes -
          Fix Version/s 5.11.0-b1 [ 11908 ]
          admin Paul Phillips made changes -
          Rank Ranked higher
          admin Paul Phillips made changes -
          Rank Ranked lower

            People

            • Assignee:
              jonathan Jonathan Reissmueller
              Reporter:
              jonathan Jonathan Reissmueller
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 5 minutes
                5m
                Remaining:
                Remaining Estimate - 5 minutes
                5m
                Logged:
                Time Spent - Not Specified
                Not Specified