Uploaded image for project: 'OpenShift Installer'
  1. OpenShift Installer
  2. CORS-2087

Installer improvements to provide user controls to extend bootstrap timeouts

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • openshift/installer
    • None
    • Provide user controls to extend bootstrap timeouts
    • BU Product Work
    • False
    • None
    • False
    • Not Selected
    • Done
    • OCPSTRAT-463 - Make the bootstrap process timeout configurable
    • OCPSTRAT-463Make the bootstrap process timeout configurable
    • 75% To Do, 0% In Progress, 25% Done

      OCP/Telco Definition of Done
      Epic Template descriptions and documentation.

      <--- Cut-n-Paste the entire contents of this description into your new Epic --->

      Epic Goal

      • To provide the user (cloud admin) with a way to indicate to the Installer that the bootstrap process could take longer due to known conditions in the environment like long POST times for HW and/or slow image downloads etc
      • The Installer should do a better job at detecting a real failure and not try to use the expiration of a timeout as a reason to report failure.  

      Why is this important?

      • The Installer should be able to accommodate environments where baremetal boot times could be slower than the hard-coded timeouts built into the Installer. This has been detected more frequently in Metal platform installs and more recently during AWS provisioning of baremetal severs. It is not always possible to accurately determine the correct timeout defaults that accommodates all situations and is also reasonable enough to detect actual failures quickly, so it would be better for the cloud admin to be able to extend these timeouts dynamically based on values observed on their environment.

      Scenarios

      1. ...

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      Open questions::

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

              sdasu@redhat.com Sandhya Dasu
              sdasu@redhat.com Sandhya Dasu
              Yunfei Jiang Yunfei Jiang
              Votes:
              3 Vote for this issue
              Watchers:
              17 Start watching this issue

                Created:
                Updated: