Jump to: Complete Features | Incomplete Features | Complete Epics | Incomplete Epics | Other Complete |
Note: this page shows the Feature-Based Change Log for a release
These features were completed when this image was assembled
When this image was assembled, these features were not yet completed. Therefore, only the Jira Cards included here are part of this release
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:
Lifecycle Information:
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:
Prioritized epics + deliverables (in scope / not in scope):
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:
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:
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:
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:
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.
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.
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
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 |
Questions to be addressed:
Goal
Provide a dynamic extensible mechanism to add Guided Tours to the OCP Console.
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
Dependencies (internal and external)
Previous Work (Optional):
Open questions::
Done Checklist
As user I would like to see a YAMLSample for the new QuickStart CRD when I go and create my own QuickStarts.
We need a README about the submission process for adding quick starts to the console-operator repo.
OpenShift console supports new features and elevated experience for Operator Lifecycle Manager (OLM) Operators and Cluster Operators.
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,
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.
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)?
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.
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
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.
URL/k8s/cluster/config.openshift.io~v1~OperatorHub/cluster/sources
See current console screenshots in the attachments for reference:
Improve ‘CatalogSource’ details view (on the “Details” tab)
The Sources tab list view now includes 2 new columns for the Catalog Sources:
Action menu changes:
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
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)?
The inventory card needs a couple of visual tweaks:
Attaching the desired design from Michael
Feature Overview
This will be phase 1 of Internationalization of the OpenShift Console.
Phase 1 will include the following:
Phase 1 will not include:
Initial List of Languages to Support
---------- 4.7* ----------
*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 ----------
POC
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
Assumptions
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.
We have too many namespaces if we're loading them upfront. We should consolidate some of the files.
Externalize strings in the User Management nav section (Users, Groups, Service Accounts, Roles, Role Bindings).
Check in translations from Sprint 192.
Externalize strings in the Builds nav section (Build Configs, Builds, Image Streams).
Externalize strings in the Monitoring nav section (Alerting, Metrics, Dashboards).
Bump i18next dependencies to the latest versions.
Externalize strings in the pages under the console Home nav section.
Externalize strings for Home / Events section
Externalize strings for Home / project / dashboard section
Externalize strings in Home / Explore pages
externalize strings for the home / search page
externalize strings for home / namespace pages
Add zh-cn and ja-jp translations.
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#
Externalize strings in the Compute nav section (Nodes, Machines, Machine Sets, Machine Autoscalers, Machine Health Checks, Machine Configs, Machine Config Pools).
Update i18n files/scripts to support Korean in advance of translation work from Terry.
Specifically:
Externalize strings in the pages under the console Workloads nav section.
i18n for Replication Controllers
i18n for Horizontal Pod AutoScalers
We need to translate following common components used in the list and details pages:
Includes list page component, filter toolbar, details page breadcrumbs, resource summary/details item, common details page headings, managed by operator link, and the conditions table.
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
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.
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.
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).
See this hackday PR
for an alternative approach which uses a configmap per imagestream
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.
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
Convert labels tests to Cypress.
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.
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.
We should update yarn to the latest version.
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:
As a user of OpenShift
I want to import OCI images
So that I can use images that are built by new tools
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Add pertinent notes here:
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
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Add pertinent notes here:
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
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Add pertinent notes here:
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.
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.
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:
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
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Add pertinent notes here:
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
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
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.
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.
Add a popover for pod status that shows additional details for unschedulable and failing pods.
The search icon & clear icon get shifted to the next line when text is entered.
None
Always
4.7.0-0.nightly-2021-02-04-031352
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
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.
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!