Feature Overview (aka. Goal Summary)  

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

Support iterative development by enabling OLMv1 to work both with a TechPreviewNoUpgrade feature set and a GeneralAvailability feature set.

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. Complete during New status.

• Users will be able to opt into testing out new features via TechPreviewNoUpgrade
• Users will be able to use OLMv1 GA features without the risk of TechPreview features

Requirements (aka. Acceptance Criteria):

A list of specific needs or objectives that a feature must deliver in order to be considered complete.  Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc.  Initial completion during Refinement status.

• All necessary infrastructure in place to enable the use of feature gates
• CI jobs to ensure that nothing from the TechPreviewNoUpdate feature set breaks OLMv1

Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

• OLMv1 will soon need a mechanism for supporting alpha/beta fields in CRDs, but it has been decided to explore this as a separate effort.

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

Before OCP 4.18 the entirety of OLMv1 was under the TechPreviewNoUpgrade feature set which allowed us to make breaking API changes without having to provide an upgrade path. Starting from OCP 4.18 OLMv1 is part of the default OCP payload and default feature set which means that we need to maintain API compatibility.

At the same time OLMv1 is still in active development and we are looking to introduce more features and deeper integration with OCP which might span multiple releases to reach completeness and stability (such as OCP web console integration). To enable iterative development we might want to put some of the new features under TechPreviewNoUpgrade feature set while maintaining a set of stable features at the same time. Effectively this means that OLMv1 will need to work both with TechPreviewNoUpgrade and without it but will have a different set of features.

Customer Considerations

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

<your text here>

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. Initial completion during Refinement status.

• Will need documentation on how to enable the TechPreviewNoUpgrade feature set

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

<your text here>