Prepare for Y ReleasePrepare for Z ReleaseRemove QuarterXMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Done
    • Icon: Undefined Undefined
    • 1.3
    • None
    • Core platform
    • None
    • False
    • Hide

      None

      Show
      None
    • False
    • 0% To Do, 0% In Progress, 100% Done

      Feature Overview (aka. Goal Summary)

      An elevator pitch (value statement) that describes the Feature in a clear,
      concise way.

      • There are areas of RHDH that do not have sufficient error logging which impacts the serviceability of RHDH

      Goals (aka. expected user outcomes)

      The observable functionality that the user now has as a result of receiving
      this feature. Include the anticipated primary user type/persona and which
      existing features, if any, will be expanded.

      • Improve error logging to allow customers to self-diagnose and/or open support tickets with sufficient information to troubleshoot

      Requirements (aka. Acceptance Criteria):

      A list of specific needs or objectives that a feature must deliver in order
      to be considered complete. If the feature spans across releases then good
      to have scope for each release with acceptance criteria. Be sure to
      include nonfunctional requirements such as security, reliability,
      performance, maintainability, scalability, usability, etc.

      • This feature may span releases as we discover new areas to address.
      • We should come up with a consistent format for messages (e.g. type: error/warning/info, location: function/line#, message: <what is the problem and how should it be resolved?>
      • User errors should be as descriptive as possible to allow customers to resolve on their own
        System errors should be as descriptive as possible to allow support to quickly identify where the problems occurred. 
      • We can consider having a wrapper around upstream messages in order to conform to this format. 
      • Optionally, we can consider message codes so lookup/documentation is easier

      Out of Scope (Optional)

      Message codes would be nice but this would be a first for RH products

      Customer Considerations (Optional)

      Provide any additional customer-specific considerations that must be made
      when designing and delivering the Feature. Initial completion during
      Refinement status.

       

      Documentation Considerations

      Provide information that needs to be considered and planned so that
      documentation will meet customer needs. If the feature extends existing
      functionality, provide a link to its current documentation.

      • Add instructions to collect logs to a MustGather page (if it exists)
      • If we do support message codes, we need to add that to the product docs

              Unassigned Unassigned
              ktsao@redhat.com Kim Tsao
              RHIDP - Core Platform
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: