Back to index

4.7.28

Jump to: Complete Features | Incomplete Features | Complete Epics | Incomplete Epics | Other Complete |

Changes from 4.6.62

Note: this page shows the Feature-Based Change Log for a release

Complete Features

These features were completed when this image was assembled

Feature OCPPLAN-4333: The details of this Jira Card are restricted (Only Red Hat employees and contractors)
The details of this Jira Card are restricted (Only Red Hat employees and contractors)
Epic CORS-1512: AWS: Support for C2S Region

Goal:

As an administrator, I would like to deploy OpenShift 4 clusters to AWS C2S region

Problem:

Customers were able to deploy to AWS C2S region in OCP 3.11, but our global configuration in OCP 4.1 doesn't support this.
  

Why is this important:

  • Many of our public sector customers would like to move off 3.11 and on to 4.1, but missing support for AWS C2S region will prevent them from being able to migrate their environments..

Lifecycle Information:

  • Core

Previous Work:**

Here are the relevant PRs from OCP 3.11.  You can see that these endpoints are not part of the standard SDK (they use an entirely separate SDK).  To support these regions the endpoints had to be configured explicitly.

Seth Jennings has put together a highly customized POC.

Dependencies:

  • Custom API endpoint support w/ CA
    • Cloud / Machine API
    • Image Registry
    • Ingress
    • Kube Controller Manager
    • Cloud Credential Operator
    • others?
  • Require access to local/private/hidden AWS environment

 

Prioritized epics + deliverables (in scope / not in scope):

  • Allow AWS C2S region to be specified for OpenShift cluster deployment
  • Enable customers to use their own managed internal/cluster DNS solutions due to provider and operational restrictions
  • Document deploying OpenShift to AWS C2S region
  • Enable CI for the AWS C2S region

Related : https://jira.coreos.com/browse/CORS-1271

Estimate (XS, S, M, L, XL, XXL): L

 

Customers: North America Public Sector and Government Agencies

Open Questions:

 

 

 

Incomplete Features

When this image was assembled, these features were not yet completed. Therefore, only the Jira Cards included here are part of this release

Feature OCPPLAN-3342: The details of this Jira Card are restricted (Only Red Hat employees and contractors)
The details of this Jira Card are restricted (Only Red Hat employees and contractors)
Feature OCPPLAN-4333: The details of this Jira Card are restricted (Only Red Hat employees and contractors)
The details of this Jira Card are restricted (Only Red Hat employees and contractors)
Feature OCPPLAN-5083: The details of this Jira Card are restricted (Only Red Hat employees and contractors)
The details of this Jira Card are restricted (Only Red Hat employees and contractors)
Feature OCPPLAN-8029: Console: Dynamic Plugin Framework

Feature Overview

Plugin teams need a mechanism to extend the OCP console that is decoupled enough so they can deliver at the cadence of their projects and not be forced in to the OCP Console release timelines.

The OCP Console Dynamic Plugin Framework will enable all our plugin teams to do the following:

  • Extend the Console
  • Deliver UI code with their Operator
  • Work in their own git Repo
  • Deliver at their own cadence

Goals

    • Operators can deliver console plugins separate from the console image and update plugins when the operator updates.
    • The dynamic plugin API is similar to the static plugin API to ease migration.
    • Plugins can use shared console components such as list and details page components.
    • Shared components from core will be part of a well-defined plugin API.
    • Plugins can use Patternfly 4 components.
    • Cluster admins control what plugins are enabled.
    • Misbehaving plugins should not break console.
    • Existing static plugins are not affected and will continue to work as expected.

Out of Scope

    • Initially we don't plan to make this a public API. The target use is for Red Hat operators. We might reevaluate later when dynamic plugins are more mature.
    • We can't avoid breaking changes in console dependencies such as Patternfly even if we don't break the console plugin API itself. We'll need a way for plugins to declare compatibility.
    • Plugins won't be sandboxed. They will have full JavaScript access to the DOM and network. Plugins won't be enabled by default, however. A cluster admin will need to enable the plugin.
    • This proposal does not cover allowing plugins to contribute backend console endpoints.

 

Requirements

 

Requirement Notes isMvp?
 UI to enable and disable plugins    YES 
 Dynamic Plugin Framework in place    YES 
Testing Infra up and running   YES 
 Docs and read me for creating and testing Plugins    YES 
CI - MUST be running successfully with test automation This is a requirement for ALL features. YES
Release Technical Enablement Provide necessary release enablement details and documents. YES

 
 Documentation Considerations

Questions to be addressed:

  • What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?
  • Does this feature have doc impact?  
  • New Content, Updates to existing content,  Release Note, or No Doc Impact
  • If unsure and no Technical Writer is available, please contact Content Strategy.
  • What concepts do customers need to understand to be successful in [action]?
  • How do we expect customers will use the feature? For what purpose(s)?
  • What reference material might a customer want/need to complete [action]?
  • Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available.
  • What is the doc impact (New Content, Updates to existing content, or Release Note)?
Epic CONSOLE-2368: The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
Story CONSOLE-2376: Complete API and console operator changes to support dynamic plugins

Dynamic plugins will need changes to the console operator config to be enabled and disabled. We'll need either a new CRD or an annotation on CSVs for console to discover when plugins are available.

This story tracks any API updates needed to openshift/api and any operator updates needed to wire through dynamic plugins as console config.

See https://github.com/openshift/enhancements/pull/441 for design details.

Story CONSOLE-2405: Add support for using dynamic extensions in static plugins

Console static plugins, maintained as part of the frontend monorepo, currently use static extension types (packages/console-plugin-sdk/src/typings) which directly reference various kinds of objects, including React components and arbitrary functions.

To ease the long-term transition from static to dynamic plugins, we should support a use case where an existing static plugin goes through the following stages:

  1. use static extensions only (we are here)
  2. use both static and dynamic extensions
  3. use dynamic extensions only (ideal target for 4.7)

Once a static plugin reaches the "use dynamic extensions only" stage, its maintainers can move it out of the Console monorepo - the plugin becomes dynamic, shipped via the corresponding operator and loaded by Console app at runtime.

Feature OCPPLAN-8036: Console: QuickStart Extensions

 

Feature Overview

Quick Starts are key tool for helping our customer to discover and understand how to take advantage of services that run on top of the OpenShift Platform. This feature will focus on making the Quick Starts extensible. With this Console extension our customer and partners will be able to add in their own Quick Starts to help drive a great user experience.

Enhancement PR: https://github.com/openshift/enhancements/pull/360 

Goals

  • Provide a supported API that our internal teams, external partners and customers can use to create Quick Starts for the OCP Console.( QUICKSTART CRD)
  • Provide proper documentation and templates to make it as easy as possible to create Quick Starts
  • Update the Console Operator to generate Quick Starts for enabling key services on the OCP Clusters:
    • Serverless
    • Pipelines
    • Virtualization
    • OCS
    • ServiceMesh
  • Process to validate Quick Starts for each release (Internal Teams Only)
  • Support Internationalization

Requirements

 

Requirement Notes isMvp?
Define QuickStart CRD   YES
Console Operator: Out of the box support for installing Quick Starts for enabling Operators   YES
Process( Design\Review), Documentation + Template for providing out of the box quick starts   YES
Process, Docs, for enabling Operators to add Quick Starts   YES
Migrate existing UI to work with CRD    
Move Existing Quick Starts to new CRD   YES
Support Internationalization   NO
CI - MUST be running successfully with test automation This is a requirement for ALL features. YES
Release Technical Enablement Provide necessary release enablement details and documents. YES

 

Documentation Considerations

Questions to be addressed:

  • What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?
  • Does this feature have doc impact?  
  • New Content, Updates to existing content,  Release Note, or No Doc Impact
  • If unsure and no Technical Writer is available, please contact Content Strategy.
  • What concepts do customers need to understand to be successful in [action]?
  • How do we expect customers will use the feature? For what purpose(s)?
  • What reference material might a customer want/need to complete [action]?
  • Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available.
  • What is the doc impact (New Content, Updates to existing content, or Release Note)?
Epic CONSOLE-2232: Console: Quick Starts: Extensibility

Goal

Provide a dynamic extensible mechanism to add Guided Tours to the OCP Console.

  • Format of Guided Tours (Almost like Interactive Documentation)
    • Markup language
    • Made up of Long Description, Steps, Links(Internal, External), Images
    • Steps should be links to the page. User navigates to the next page by clicking a button
    • A tour may offer a link to a secondary tour
    • A tour may offer an external link to documentation, etc
    • Progress indicator, indicating the number of steps in the tour
    • Perspective
  • Tour information to be displayed on the Cards in the landing page
    • Title
    • Summary (aka Short Desc)
    • Image
    • Approx time
    • Perspective
    • Indication if already completed (local storage, maybe this is punted til User Pref)

User Stories/Scenarios
As a product owner, I need a mechanism to add guide tours that will help guide my users to enable my service.
As a product owner, I need a mechanism to add guide tours that will help guide my users to consume my service.
As an Operator, I need a mechanism to add guide tours that will help guide my users to consume my service.

+Acceptance Criteria

  • CI - MUST be running successfully with tests automated
  • ...

Dependencies (internal and external)

  1. ...

Previous Work (Optional):

  1. …

Open questions::

  1. …

Done Checklist

  • CI - CI is running, tests are automated and merged.
  • 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>
Task CONSOLE-2479: Add YAML Sample for QuickStart CRD

As user I would like to see a YAMLSample for the new QuickStart CRD when I go and create my own QuickStarts.

 

Epic Goal

  • ...

Why is this important?

  • …

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):

  1. …

Open questions::

  1. …

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>
Feature OCPPLAN-8037: OLM UI: Operator first-class experience

Feature Overview

OpenShift console supports new features and elevated experience for Operator Lifecycle Manager (OLM) Operators and Cluster Operators.

Goal:

OCP Console improves the controls and visibility for managing vendor-provided software in customers’ infrastructure and making these solutions available for customers' internal users.

 

To achieve this, 

  • Operator Lifecycle Manager (OLM) teams have been introducing new features aiming towards simplification and ease of use for both developers and cluster admins.
  • On the Cluster Operators side, the console iteratively improves the visibilities to the resources being associated with the Operators to improve the overall managing experience.

We want to make sure OLM’s and Cluster Operators' new features are exposed in the console so admin console users can benefit from them.

Benefits:

  • Cluster admin/Operator consumers:
    • Able to see, learn, and interact with OLM managed and/or Cluster Operators associated resources in openShift console.

Requirements

Requirement Notes isMvp?
OCP console supports the latest OLM APIs and features This is a requirement for ALL features. YES
OCP console improves visibility to Cluster Operators related resources and features. This is a requirement for ALL features. YES
     

 

(Optional) Use Cases
<--- Remove this text when creating a Feature in Jira, only for reference --->
* Main success scenarios - high-level user stories
* Alternate flow/scenarios - high-level user stories
* ...

Questions to answer...
How will the user interact with this feature?
Which users will use this and when will they use it?
Is this feature used as part of the current user interface?

Out of Scope
<--- Remove this text when creating a Feature in Jira, only for reference --->
# List of non-requirements or things not included in this feature
# ...

Background, and strategic fit
<--- Remove this text when creating a Feature in Jira, only for reference --->
What does the person writing code, testing, documenting need to know? What context can be provided to frame this feature.

Assumptions
<--- Remove this text when creating a Feature in Jira, only for reference --->
* Are there assumptions being made regarding prerequisites and dependencies?
* Are there assumptions about hardware, software or people resources?
* ...

Customer Considerations
<--- Remove this text when creating a Feature in Jira, only for reference --->
* Are there specific customer environments that need to be considered (such as working with existing h/w and software)?
...

Documentation Considerations
<--- Remove this text when creating a Feature in Jira, only for reference --->
Questions to be addressed:
* What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?
* Does this feature have doc impact?
* New Content, Updates to existing content, Release Note, or No Doc Impact
* If unsure and no Technical Writer is available, please contact Content Strategy.
* What concepts do customers need to understand to be successful in [action]?
* How do we expect customers will use the feature? For what purpose(s)?
* What reference material might a customer want/need to complete [action]?
* Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available.
* What is the doc impact (New Content, Updates to existing content, or Release Note)?

Epic CONSOLE-2244: Improve Cluster Config ‘OperatorHub’ and ‘CatalogSource’ views for new OLM features

Background:

OpenShift console allows users (cluster admins) to change the state of the “default hub sources” for OperatorHub on the cluster from “enabled” to “disabled” and vice versa through “Global Configuration → OperatorHub” view from the “Cluster Settings” view.

Starting from OpenShift 4.4, the console and OLM provides richer configurations for the ‘CatalogSource’ objects that enable users to create their curated sources for OperatorHub with custom “Display Name”, “URL of Image Registry”, and the “Polling Interval” for updating the custom OperatorHub source.

This epic is about reflecting/exposing the newer capabilities on the ‘OperatorHub’ (Cluster Config view) and the ‘CatalogSource’ list and details views.

Goals:

1. As an admin user of console, I'd like to:
easily disable/enable the predefined Operator sources for the OperatorHub

so that I can:
control the sources of the Operators my cluster users see on the OperatorHub view.

2. As an admin user of console, I'd like to:
easily understand how to add/edit/view/remove my custom Operator catalogSource for the OperatorHub

so that I can
easier managing (add/edit/view/remove) my custom sources for the OperatorHub

3. As an admin user of console, I'd like to:
easily see the configurations and status of my custom Operator catalogSource for the OperatorHub

so that I can
easier managing (review/edit) the configurations of my custom sources for the OperatorHub

Acceptance Criteria:

  1. Improve cluster config: ‘OperatorHub’ Detail view
    • Add toggles for “disabled/enabled” predefined Operators
      • "Red Hat Operators"
      • "Certified Operators"
      • "Community Operators"
      • "Marketplace Operators"
    • Add “help text” on details view to guide users: 
      Change the state of the default hub sources for OperatorHub on the cluster from enabled to disabled and vice versa. Add and manage your curated sources for OperatorHub on the Sources tab with custom Display Name, URL of Image Registry, and the Polling Interval for updating your custom OperatorHub source.
    • Embedded a link to the "Sources" tab in the help text above: 
      URL/k8s/cluster/config.openshift.io~v1~OperatorHub/cluster/sources
      • Easier access to create/manage custom ‘CatalogSource
  2. Improve ‘CatalogSource’ list view (on the “Source” tab) and details view
    • On ‘CatalogSource’ list view:
      • Show “Catalog Polling Interval” (if `spec.sourceType: grpc`)
      • Expose “Status” (status.connectionState.lastObservedState)
    • On ‘CatalogSource’ details view:
      • Show & Edit “Catalog Polling Interval” (if `spec.sourceType: grpc`)
        --> A dropdown with options in ‘15m’, ‘30m’, ‘45m’, ‘60m’.
      • (Sync up with the list view) Expose newly introduced fields on the ‘CatalogSource’ object:
        • Expose “Status” (status.connectionState.lastObservedState)
        • Display Name (spec.displayName)
        • Publisher (spec.publisher)
        • Availability
        • Endpoint (spec.image)
        • Polling Interval
        • # of Operators
      • Add an “Operators” tab - show a list of “PackageManifests” (Operators) consists of this ‘CatalogSource‘

Current UI in OpenShift console:

See current console screenshots in the attachments for reference:

  1. Cluster config: ‘OperatorHub’ Detail view
  2. ‘CatalogSource’ list view (on the “Source” tab)
  3. ‘CatalogSource‘ Details view
  4. mocked screenshot - "Operators" tab on the ‘CatalogSource‘ Details view
Story CONSOLE-2477: Improve Operator hub "Sources" view to add additional columns & modify the Actions kebab

The Sources tab list view now includes 2 new columns for the Catalog Sources:

  • Status and Registry Poll Interval

Action menu changes:

  • For default sources: Only the existing Disable and Edit CatalogSource actions are available since any other delete or edit will immediately be reverted by the cluster operator
  • For custom sources: The menus match the Actions menu in the Catalog Source
Story CONSOLE-2457: Improve ‘CatalogSource’ Details view & add a new "Operators" tab

Improve ‘CatalogSource’ details view (on the “Details” tab)

  • On ‘CatalogSource’ details view:
    • Show & Edit “Catalog Polling Interval” (if `spec.sourceType: grpc`)
      --> A dropdown with options in ‘15m’, ‘30m’, ‘45m’, ‘60m’.
    • (Sync up with the list view) Expose newly introduced fields on the ‘CatalogSource’ object:
      • Expose “Status” (status.connectionState.lastObservedState)
      • Display Name (spec.displayName)
      • Publisher (spec.publisher)
      • Availability
      • Endpoint (spec.image)
      • Polling Interval
      • # of Operators
    • Add an “Operators” tab - show a list of “PackageManifests” (Operators) consists of this ‘CatalogSource‘
Feature OCPPLAN-8041: Console: PF4 Usability Enhancements

Feature Overview
PF4 has introduced a bevy of new components to really enhance the user experience, specifically around list views. These new components make it easier than ever for customers to find the data they care about and to take action.

Goals

  • Migrate to PF4 Components
  • Improve Search Page
    • Saved Search
  • Improve List View
    • Bulk Actions
      • delete
      • add label
      • add annotation
    • Column Management
      • Show\Hide Columns
    • Favoriting
      • Bubble favorites to the top of the list view
    • Toolbar
      • Advance Filter

Requirements

Requirement Notes isMvp?
Improvements must be applied to all resource list view pages including the search page This is a requirement for ALL features. YES
Search page will be the only page that needs "Saved Searches" This is a requirement for ALL features. NO
All components updated must be PF4 supported This is a requirement for ALL features. YES

Questions to answer...
How will the user interact with this feature?
Which users will use this and when will they use it?
Is this feature used as part of the current user interface?

Out of Scope
<--- Remove this text when creating a Feature in Jira, only for reference --->
# List of non-requirements or things not included in this feature
# ...

Background, and strategic fit
<--- Remove this text when creating a Feature in Jira, only for reference --->
What does the person writing code, testing, documenting need to know? What context can be provided to frame this feature.

Assumptions
<--- Remove this text when creating a Feature in Jira, only for reference --->
* Are there assumptions being made regarding prerequisites and dependencies?
* Are there assumptions about hardware, software or people resources?
* ...

Customer Considerations
<--- Remove this text when creating a Feature in Jira, only for reference --->
* Are there specific customer environments that need to be considered (such as working with existing h/w and software)?
...

Documentation Considerations
<--- Remove this text when creating a Feature in Jira, only for reference --->
Questions to be addressed:
* What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?
* Does this feature have doc impact?
* New Content, Updates to existing content, Release Note, or No Doc Impact
* If unsure and no Technical Writer is available, please contact Content Strategy.
* What concepts do customers need to understand to be successful in [action]?
* How do we expect customers will use the feature? For what purpose(s)?
* What reference material might a customer want/need to complete [action]?
* Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available.
* What is the doc impact (New Content, Updates to existing content, or Release Note)?

Epic CONSOLE-2249: The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
Task CONSOLE-1916: Inventory card visual updates

The inventory card needs a couple of visual tweaks:

  • the individual links should be 14px (not 16px) to be consistent with other cards
  • the order of the icon/# should be switched so that the number precedes the icon

Attaching the desired design from Michael

Feature OCPPLAN-8043: Console: Internationalization

 Feature Overview

This will be phase 1 of Internationalization of the OpenShift Console.

 Phase 1 will include the following:

  1. UI based language Selector instead of using browser detection
  2. Externalize all hard coded strings in the client code including all OpenShift static plugins
    1. Admin Console
    2. Dev Console
    3. Serverless
    4. Pipelines
    5. CNV
    6. OCS
    7. CSO
  3. Localized Date\Time
  4. Setup all processes, infrastructure, and testing required
  5. We will start with support for Chinese and Japanese lang

Phase 1 will not include:

  1. Dynamically generated UI (Operator, OpenAPIV3Schema)
    1. Operators that surface informational messages may not have translations available
  2. Strings from non client code
    1. This may include items such as events surfaced from Kuberenetes, alerts, and error messages displayed to the user or in logs
  3. Localization of logging messages at any level is not in scope
  4. Any CLI
  5. Language support for left to right languages ie Arabic

Initial List of Languages to Support

---------- 4.7* ----------

  1. Japanese - Code: ja 
  2. Chinese - Code: zh_CN, zh_TW 
  3. Korean - Code: ko

*This will be based on the ability to get all the strings externalized, there is a good chance this gets pushed to 4.8.

---------- Post 4.7 ----------

  1. Spanish: - Code: es_419, es 
  2. German: - Code: de
  3. French - Code: fr
  4. Italian - Code: it
  5. Portuguese - Code: pt_BR
  6. Korean - Code: ko
  7. Hindi - Code: hi

POC

 Initial POC PR

Goals

Internationalization has become table stakes. OpenShift Console needs to support different languages in each of the major markets. This is key functionality that will help unlock sales in different regions.

 

Requirements

 

Requirement Notes isMvp?
Language Selector   YES
Localized Date. + Time   YES
Externalization and translation of all client side strings   YES
Translation for Chinese and Japanese   YES
Process, infra, and testing capabilities put into place   YES
CI - MUST be running successfully with test automation This is a requirement for ALL features. YES
     

  

Out of Scope

  1. Dynamically generated UI (Operator, OpenAPIV3Schema)
    1. Operators that surface informational messages may not have translations available
  2. Strings from non client code
    1. This may include items such as events surfaced from Kuberenetes, alerts, and error messages displayed to the user or in logs
  3. Localization of logging messages at any level is not in scope
  4. Any CLI support
  5. Language support for left to right languages ie. Arabic

 

Assumptions

  • Each static plugin team will be responsible for externalizing all their client code strings.
  • Quick Starts will need to be translated.

Customer Considerations

We are rolling this feature in phases, based on customer feedback, there may be no phase 2.

Documentation Considerations

I believe documentation already supports a large language set.

Epic CONSOLE-2527: Internationalization Cont. - 4.8

Epic Goal

  • This is the continuation of the Internationalization work... the following items remain:
    • All existing QuickStarts get Translated
    • Automation Completed
    • Any remaining items cleaned up

Why is this important?

  • Automating as much as possible with the detecting duplicate strings, building, translation drops will ensure we will be successful for all future releases
  • Quick Start are important part of the product that enable our users to maximize usage of the Console
  • Best to clean up anything left over to reduce future Tech Debt

Acceptance Criteria

  • Quick Starts are translated 
  • Everything is automated for building, and pushing translation drops to the globalization team
  • Source code should be up to quality standards

Previous Work (Optional):

  1. https://issues.redhat.com/browse/CONSOLE-2325

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>
Story CONSOLE-2487: Consolidate i18n namespaces

We have too many namespaces if we're loading them upfront. We should consolidate some of the files.

Epic CONSOLE-2325: Console: Internationalization - Admin

Goal

  • Localize OpenShift Admin Console
    • Externalize hardcoded String on the client side
    • Update Capitalization for Strings
    • Add a language selector under User Menu
    • Localize date + time
    • Setup Build system
    • Setup CI system 

Why is this important?

  • Our goal should be to make OCP Console accessible to everyone. By providing different language support we open up OCP to many people that previously couldn't use the Console because of language barriers.

  

Acceptance Criteria

  • Release Technical Enablement

 

Story CONSOLE-2392: i18n: externalize strings in Compute nav section

Externalize strings in the Compute nav section (Nodes, Machines, Machine Sets, Machine Autoscalers, Machine Health Checks, Machine Configs, Machine Config Pools).

Story CONSOLE-2393: i18n: externalize strings in User Management nav section

Externalize strings in the User Management nav section (Users, Groups, Service Accounts, Roles, Role Bindings).

Story CONSOLE-2369: i18n: externalize strings in Workloads pages

Externalize strings in the pages under the console Workloads nav section.

Story CONSOLE-2395: i18n: add language selector to console

By default, we should use the user's browser preference for language, but we should give users a language selector to override. Here is a proposed design:

https://docs.google.com/document/d/17iIBDlEneu0DNhWi2TkQShRSobQZubWOhS0OQr_T3hE/edit#

Story CONSOLE-2416: i18n: Translate common component used by list and details pages

We need to translate following common components used in the list and details pages:

  • Common ListPage component
  • Column management modal
  • Common list view kebab
  • Common filter toolbar
  • Details page breadcrumbs
  • ResourceSummary/DetailsItem component
  • Details page Actions dropdown
  • Common details page tabs
  • Managed by operator link
  • Conditions table
  • Common dropdown component
Task CONSOLE-2461: Add infrastructure for Korean

Update i18n files/scripts to support Korean in advance of translation work from Terry.

Specifically:

Complete Epics

This section includes Jira cards that are linked to an Epic, but the Epic itself is not linked to any Feature. These epics were completed when this image was assembled

Epic BUILD-144: The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
Story BUILD-125: Improve recording of imagestream import results

User Story

Sample operator use of the reason field in its config object to track imagestream import completion has resulted in that singleton being a bottleneck and source of update conflicts (we are talking 60 or 70 imagestreams potentially updating that once field concurrently).

Acceptance Criteria

  • Reduction in reconciliation errors when imagestream imports complete (success or failure).
  • ConfigMaps containing failing imagstream imports are added to must-gather
  • After all imagestreams successfully import, there are no error-recording ConfigMaps in the samples-operator namespace.

Notes

See this hackday PR

for an alternative approach which uses a configmap per imagestream

Story BUILD-145: Fix usability with mirroring sample images in disconnected environments

User Story

As an cluster administrator of a disconnected OCP cluster,
I want a list of possible sample images to mirror
So that I can configure my image mirror prior to installing OCP in a disconnected environment.

Acceptance Criteria

  • Publish the list of the sample images to mirror as a ConfigMap in the samples operator namespace.
  • Provide instructions on how to obtain the current image SHAs from the list above (via podman or skopeo).
  • Reference the ConfigMap name in our "import failing" alert.
  • [optional] Reference the ConfigMap name in our "Removed" condition message.

Notes

it is too onerous to find a connected cluster in order to obtain the list of possible samples images to mirror using the current documented procedures.
I need a list make available to me in my disconnected cluster that I can reference after initial install.

Epic CONSOLE-2216: Convert existing test to Cypress e2e tests

We should expand the set of Cypress e2e tests we started in 4.6. This can either be new tests, or migrating some of our more flaky protractor tests.

Story CONSOLE-2502: Migrate the remaining CRUD tests to Cypress

We still have some tests remaining in the Protractor CRUD scenario:

https://github.com/openshift/console/blob/master/frontend/integration-tests/tests/crud.scenario.ts

We should migrate these to Cypress.

Acceptance Criteria

  • All remaining CRUD tests have been migrated to Cypress and are running in CI.
  • The old CRUD scenario is removed from Protractor.
  • The new CRUD tests are running as part of the periodic release tests against console (should not require code change).
Epic CONSOLE-2275: 4.7 Console Dependencies & Tech Debt

An epic we can duplicate for each release to ensure we have a place to catch things we ought to be doing regularly but can tend to fall by the wayside.

Story CONSOLE-2296: Bump dependencies for front end code for 4.7

It has been a few releases since we've gone through and updated the various frontend dependencies for console. We should update major dependencies such as TypeScript, React, and webpack.

We should consider updating our TypeScript typings as well, which have gotten out of date.

Epic IR-115: OCI Support

Goal: Support OCI images.

Problem: Buildah and podman use OCI format by default and OpenShift Image Registry and ImageStream API doesn't understand it.

Why is this important: OCI images are supposed to replace Docker schema 2 images, OpenShift should be ready when OCI images become widely adopted.

Dependencies (internal and external):

Prioritized epics + deliverables (in scope / not in scope):

Estimate (XS, S, M, L, XL, XXL): XL

Previous Work:

Customers:

Open Questions:

Story IR-112: Add support of OCI images to image pruner

User Story

As a user of OpenShift
I want the image pruner to be aware of OCI images
So that it doesn't delete their layers/configs

Acceptance Criteria

    • When
      • an OCI image is pushed/mirrored to the registry
      • an schema 2 image is pushes/mirrored to the registry and share its layers/config with the OCI image
      • the schema 2 image is eligible to be pruned
      • the shared layers/config are not shared with other images
    • the pruner
      • will delete the schema 2 image
      • will NOT delete the OCI image and its layers/config

Launch Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Notes

Add pertinent notes here:

  • Enhancement proposal link
  • Previous product docs
  • Best practices
  • Known issues

Guiding Questions

User Story

  • Is this intended for an administrator, application developer, or other type of OpenShift user?
  • What experience level is this intended for? New, experienced, etc.?
  • Why is this story important? What problems does this solve? What benefit(s) will the customer experience?
  • Is this part of a larger epic or initiative? If so, ensure that the story is linked to the appropriate epic and/or initiative.

Acceptance Criteria

  • How should a customer use and/or configure the feature?
  • Are there any prerequisites for using/enabling the feature?

Notes

  • Is this a new feature, or an enhancement of an existing feature? If the latter, list the feature and docs reference.
  • Are there any new terms, abbreviations, or commands introduced with this story? Ex: a new command line argument, a new custom resource.
  • Are there any recommended best practices when using this feature?
  • On feature completion, are there any known issues that customers should be aware of?
Story IR-113: Add support of OCI images to API server

User Story

As a user of OpenShift
I want to import OCI images
So that I can use images that are built by new tools

Acceptance Criteria

  • oc import-image works with OCI images

Launch Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Notes

Add pertinent notes here:

Guiding Questions

User Story

  • Is this intended for an administrator, application developer, or other type of OpenShift user?
  • What experience level is this intended for? New, experienced, etc.?
  • Why is this story important? What problems does this solve? What benefit(s) will the customer experience?
  • Is this part of a larger epic or initiative? If so, ensure that the story is linked to the appropriate epic and/or initiative.

Acceptance Criteria

  • How should a customer use and/or configure the feature?
  • Are there any prerequisites for using/enabling the feature?

Notes

  • Is this a new feature, or an enhancement of an existing feature? If the latter, list the feature and docs reference.
  • Are there any new terms, abbreviations, or commands introduced with this story? Ex: a new command line argument, a new custom resource.
  • Are there any recommended best practices when using this feature?
  • On feature completion, are there any known issues that customers should be aware of?
Story IR-114: Add support of OCI images to image registry

User Story

As a user of OpenShift
I want to push OCI images to the registry
So that I can use buildah and podman with their defaults to push images

Acceptance Criteria

  • An OCI image can be pushed to the registry by buildah or podman
  • An imported OCI image can be pulled from the registry
  • The registry should be able to pull-through OCI images from other registries

Launch Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Notes

Add pertinent notes here:

  • Enhancement proposal link
  • Previous product docs
  • Best practices
  • Known issues

Guiding Questions

User Story

  • Is this intended for an administrator, application developer, or other type of OpenShift user?
  • What experience level is this intended for? New, experienced, etc.?
  • Why is this story important? What problems does this solve? What benefit(s) will the customer experience?
  • Is this part of a larger epic or initiative? If so, ensure that the story is linked to the appropriate epic and/or initiative.

Acceptance Criteria

  • How should a customer use and/or configure the feature?
  • Are there any prerequisites for using/enabling the feature?

Notes

  • Is this a new feature, or an enhancement of an existing feature? If the latter, list the feature and docs reference.
  • Are there any new terms, abbreviations, or commands introduced with this story? Ex: a new command line argument, a new custom resource.
  • Are there any recommended best practices when using this feature?
  • On feature completion, are there any known issues that customers should be aware of?
Epic IR-138: Continuous Improvement of Maintainability 4.7

Epic Goal

  • Improve CI testing of the image registry components.

Why is this important?

  • The image registry, image API and the image pruner had a lot of tests removed during transition 4.0. This may make the platform less stable and/or slow down the team.

Scenarios

  1. ...

Acceptance Criteria

  • CI - tests should be more stable and have broader coverage

Dependencies (internal and external)

  1. ...

Previous Work (Optional):

  1. …

Open questions::

  1. …

Done Checklist

  • CI - CI is running, tests are automated and merged.
Task IR-172: Convert image-registry integration tests into e2e tests

The integration tests for the image registry expect that OpenShift and tests are run on the same machine (i.e. OpenShift can connect to sockets that the tests listen). This is not the case with e2e tests.

Acceptance Criteria

  • every integration test is converted into an e2e test or a techdebt story
  • image-registry tests are green
Story IR-137: Make ISI tests non-disruptive

https://github.com/openshift/origin/pull/25475/files marked our tests for ISI as Disruptive.

Tests should wait until operators become stable, otherwise other tests will be run on an unstable cluster and it'll cause flakes.

Acceptance Criteria

  • The tests wait until operators stable after image.config changes.
  • The tests is no longer [Disruptive].
  • If tests are slow (it depends on other operator, but MCO tends to be slow), they should be [Slow].
Story IR-152: Monitor availability of registry during upgrade tests

An the registry developer
I want e2e-upgrade jobs to monitor availability of the registry during upgrades
So that I can be sure that clients can use the registry without disruptions.

Acceptance Criteria

  • A new test in openshift/origin repo.

Notes

https://github.com/openshift/origin/blob/e6b3d1ece61d7c3ab5a23151c9875e1f9ad36838/test/extended/util/disruption/controlplane/controlplane.go#L69

https://bugzilla.redhat.com/show_bug.cgi?id=1884380

Epic IR-85: Rebase Registry v2.7.1

Goal: Rebase registry to Docker Distribution 

Problem: The registry is currently based on an outdated version of the upstream docker/distribution project. The base does not even have a version associated with it - DevEx last rebased on an untagged commit.

Why is this important: Update the registry with improvements and bug fixes from the upstream community.

Dependencies (internal and external):

Prioritized epics + deliverables (in scope / not in scope):

Estimate (XS, S, M, L, XL, XXL): M

Previous Work:

Customers:

 

Open questions:

Story IR-52: Rebase Image Registry to v2.7.1

User Story

As a user of OpenShift
I want the image registry to be rebased on the latest docker/distribution release (v2.7.1)
So that the image registry has the latest upstream bugfixes and enhancements

Acceptance Criteria

  • Image registry is based on docker/distribution v2.7.1

Launch Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Notes

Add pertinent notes here:

  • Enhancement proposal link
  • Previous product docs
  • Best practices
  • Known issues

Guiding Questions

User Story

  • Is this intended for an administrator, application developer, or other type of OpenShift user?
  • What experience level is this intended for? New, experienced, etc.?
  • Why is this story important? What problems does this solve? What benefit(s) will the customer experience?
  • Is this part of a larger epic or initiative? If so, ensure that the story is linked to the appropriate epic and/or initiative.

Acceptance Criteria

  • How should a customer use and/or configure the feature?
  • Are there any prerequisites for using/enabling the feature?

Notes

  • Is this a new feature, or an enhancement of an existing feature? If the latter, list the feature and docs reference.
  • Are there any new terms, abbreviations, or commands introduced with this story? Ex: a new command line argument, a new custom resource.
  • Are there any recommended best practices when using this feature?
  • On feature completion, are there any known issues that customers should be aware of?
Epic OSASINFRA-2085: The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
The details of this Jira Card are restricted (Red Hat Employee and Contractors only)

Incomplete Epics

This section includes Jira cards that are linked to an Epic, but the Epic itself is not linked to any Feature. These epics were not completed when this image was assembled

Epic OCPCLOUD-737: The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
The details of this Jira Card are restricted (Red Hat Employee and Contractors only)

Other Complete

This section includes Jira cards that are not linked to either an Epic or a Feature. These tickets were completed when this image was assembled

Story OCPCLOUD-914: The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
Task MON-1302: The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
Story CONSOLE-2024: Console: Surface pod status info

Add a popover for pod status that shows additional details for unschedulable and failing pods.

  • If pod is Unschedulable, add a popover to Pending status that includes the reason the pod is unschedulable on the pod list and pod details pages.
  • If pod status is CrashLoopBackoff, add a popover to the CrashLoopBackoff status that includes the reason for the error on the pod list and pod details pages.
  • If pod status is ErrImagePull, add a popover to the ErrImagePull status that includes the reason for the error on the pod list and pod details pages.
  • If pod status is ImagePullBackOff, add a popover to the ImagePullBackOff status that includes the reason for the error on the pod list and pod details pages.
Story CONSOLE-2523: Add resource requests to cluster and project overview

In 4.7, we have the queries to calculate the dotted line for projects and overall cluster:

sum by (exported_namespace) (kube_pod_resource_request{resource="cpu"})
sum by (exported_namespace) (kube_pod_resource_request{resource="memory"})

We should add the dotted lines to the cluster and project dashboards showing total requests for CPU and memory.

Story CONSOLE-2396: The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
Story CONSOLE-1523: The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
Task MON-1175: The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
Task MON-1208: The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
Task ETCD-178: refactor discover-etcd-initial-cluster and add tests

discover-etcd-initial-cluster was written very early on in the cluster-etcd-operator life cycle. We have observed at least one bug in this code and in order to validate logical correctness it needs to be rewritten with unit tests.

PR: https://github.com/openshift/etcd/pull/73

Story CONSOLE-2426: Optimize Cypress yarn scripts

Currently, to launch the Cypress test runner GUI, in frontend/package.json we have:

"test-cypress": "cd packages/integration-tests-cypress && cypress open ...",
 "test-cypress-devconsole": "cd packages/dev-console/integration-tests && cypress open...",
 "test-cypress-olm": "cd packages/operator-lifecycle-manager/integration-tests-cypress && cypress open ..."

We want one "test-cypress" command which takes a 'pkg' parameter, values of 'olm', 'devconsole', 'console'(default).

This will cd to correct dir and use any other config settings needed for olm cypress testing:

yarn run test-cypress olm

 

We also have cypress headless yarn scripts:

"test-cypress-headless": "yarn run test-cypress-console-headless && yarn run test-cypress-devconsole-headless && yarn run test-cypress-olm-headless",
 "test-cypress-console-headless": "cd packages/integration-tests-cypress && cypress run ...",
 "test-cypress-devconsole-headless": "cd packages/dev-console/integration-tests && cypress run --spec \"features/project-creation.feature\"
 "test-cypress-olm-headless": "cd packages/operator-lifecycle-manager/integration-tests-cypress && cypress run --config-file cypress-olm.json"

We want to extend the aforementioned `test-cypress` command to take a '--headless' parmeter which will run the pkg in --headless mode:

"yarn run test-cypress olm --headless"

This would replace the individual "test-cypress-<pkg>-headless" yarn scripts (if possible).

 

test-cypress.sh will need to be updated accordingly!

Bug ODC-5487: Quick start search bar's icons shift to next line on input

Description of problem:

The search icon & clear icon get shifted to the next line when text is entered.

Prerequisites (if any, like setup, operators/versions):

None

Steps to Reproduce

  1. Enter text in the quick start search bar.

 

Reproducibility (Always/Intermittent/Only Once):

Always

Build Details:

4.7.0-0.nightly-2021-02-04-031352

Additional info:

Appears to be a Patternfly bug: https://github.com/patternfly/patternfly-react/issues/5416

Originated from pf upgrade to fix another issue: https://github.com/openshift/console/pull/7899

Story CONSOLE-2464: Collapse managedFields by default in YAML

Various resources have a large `metadata.mangedFields` stanza that isn't important for users. We should see if we can collapse that section by default in the YAML editor.

I didn't see an obvious API in Monaco editor for doing this, but I could have missed it. We can reach out to the dev tools team who own the YAML language server to see if it's possible.

cc Ali Mobrem Eric Paris