Uploaded image for project: 'OpenShift Logging'
  1. OpenShift Logging
  2. LOG-1766

Define, document, and implement strategy for releasing preview features

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Obsolete
    • Icon: Major Major
    • None
    • None
    • Log Collection, Log Storage
    • None
    • Logging Preview Releases
    • False
    • False
    • NEW
    • Done
    • Impediment
    • NEW
    • 0% To Do, 0% In Progress, 100% Done

      Goals

      • Detailed description of our procedure for releasing preview features.
        • Branching, tagging and code conventions
        • Use of channels
      • Repo with a working "hello-world" code illustrating how we would release:
        • preview runtime behavior
        • preview additive API change that is rolled into current API version.
        • preview destructive API change that becomes a new API version.
        • GA release incorporating each of the changes above.
        • GA release when master contains incomplete prevew code that must be hidden from GA users.
      • Changes to core and explore repos and CPass builds to implement the strategy
      • Preview release using the strategy. Current issues that may need preview include:
        • LOG-1438 Integrate log-exploration-api into the cluster-logging-operator
        • LOG-1715 Replace fluentd with vector as the primary collector for logging

      Non-Goals

      • Avoid inventing new techniques. Follow relevant k8s, openshift and Red Hat conventions, where they exist and are clearly defined. Seek clarity where they are not.
      • Avoid writing significant new code, CI or build machinery. Use existing Golang, k8s, openshift, CPaas features as naturally as possible.

      Motivation

      We need a well-understood (by the team) repeatable procedure to release unsupported preview code for customer and/or internal testing

      Alternatives

      Never do preview releases, GA only. No possible pre-GA feedback from real users.

      Acceptance Criteria

      1. Team members, outside contributors - anyone with access to repos - can easily find out how we do preview releases.
      2. Team members who take up the "release manager" position for the first time can easily find instructions and perform the steps needed to make a preview release.
      3. Team members know what (if any) extra steps they need to take when working on code that will be previewed before the next GA.
      4. Team members know what (if an) extra steps to take if preview code is not ready at GA time,  so that the preview code will not be visible to, or affect, GA users.

      Risk and Assumptions

      Documentation Considerations

      Open Questions

      Additional Notes

              rhn-engineering-aconway Alan Conway
              rhn-engineering-aconway Alan Conway
              Anping Li Anping Li
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: