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
Epic Goal
- Support running console in single-node OpenShift configurations for production use in edge computing use cases.
- Support disabling the console entirely in some of these configurations to reduce overhead in constrained environments.
Why is this important?
- Some bare metal edge customers, especially in the telco market, want to use kubernetes at physically remote sites with minimal hardware.
Scenarios
- As a user, I want to deploy a fully supported instance of OpenShift on a single node.
Acceptance Criteria
- CI - MUST be running successfully with tests automated
- Release Technical Enablement - Provide necessary release enablement details and documents.
- console can be deployed with a single replica
Dependencies (internal and external)
Previous Work (Optional):
- https://github.com/openshift/enhancements/pull/504
- https://github.com/openshift/enhancements/pull/560
Open questions::
- Should the console configuration API have a separate option for this setting, or should it use the API created from
CORS-1589?
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>
https://github.com/openshift/enhancements/pull/555
https://github.com/openshift/api/pull/827
The console operator will need to support single-node clusters.
We have a console deployment and downloads deployment. Each will to be updated so that there's only a single replica when high availability mode is disabled in the Infrastructure config. We should also remove the anti-affinity rule in the console deployment that tries to spread console pods across nodes.
The downloads deployment is currently a static manifest. That likely needs to be created by the console operator instead going forward.
Acceptance Criteria:
- Console operator deploys console with 1 replica and no anti-affinity rules when not in high availability mode
- Console operator deploys the downloads deployment with 1 replica when not in high availability mode
- The console and downloads deployments do not change when in high availability mode
- The feature is well-covered by tests
Bump github.com/openshift/api to pickup changes from openshift/api#827
Feature Overview
We drive OpenShift cross-market customer success and new customer adoption with constant improvements and feature additions to the existing capabilities of our OpenShift Core Networking (SDN and Network Edge). This feature captures that natural progression of the product.
Goals
- Feature enhancements (performance, scale, configuration, UX, ...)
- Modernization (incorporation and productization of new technologies)
Requirements
- Core Networking Stability
- Core Networking Performance and Scale
- Core Neworking Extensibility (Multus CNIs)
- Core Networking UX (Observability)
- Core Networking Security and Compliance
In Scope
- Network Edge (ingress, DNS, LB)
- SDN (CNI plugins, openshift-sdn, OVN, network policy, egressIP, egress Router, ...)
- Networking Observability
Out of Scope
There are definitely grey areas, but in general:
- CNV
- Service Mesh
- CNF
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)?
The multiple destinations provided as a part of the allowedDestinations field is not working as it used to on OCP4: https://github.com/openshift/images/blob/master/egress/router/egress-router.sh#L70-L109
We need to parse this from the NAD and modify the iptables here to support them:
https://github.com/openshift/egress-router-cni/blob/master/pkg/macvlan/macvlan.go#L272-L349
Testing:
1) Created NAD:
[dsal@bkr-hv02 surya_multiple_destinations]$ cat nad_multiple_destination.yaml --- apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: egress-router spec: config: '{ "cniVersion": "0.4.0", "type": "egress-router", "name": "egress-router", "ip": { "addresses": [ "10.200.16.10/24" ], "destinations": [ "80 tcp 10.100.3.200", "8080 tcp 203.0.113.26 80", "8443 tcp 203.0.113.26 443" ], "gateway": "10.200.16.1" } }'
2) Created pod:
[dsal@bkr-hv02 surya_multiple_destinations]$ cat egress-router-pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: egress-router-pod
annotations:
k8s.v1.cni.cncf.io/networks: egress-router
spec:
containers:
- name: openshift-egress-router-pod
command: ["/bin/bash", "-c", "sleep 999999999"]
image: centos/tools
securityContext:
privileged: true
3) Checked IPtables:
[root@worker-1 core]# iptables-save -t nat Generated by iptables-save v1.8.4 on Mon Feb 1 12:08:05 2021 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A POSTROUTING -o net1 -j SNAT --to-source 10.200.16.10 COMMIT # Completed on Mon Feb 1 12:08:05 2021
As we can see, only the SNAT rule is added. The DNAT doesn't get picked up because of the syntax difference.
Create a PR in openshift/cluster-ingress-operator to specify the random balancing algorithm if the feature gate is enabled, and to specify the leastconn balancing algorithm (the current default) otherwise.
This story is for actually updating the version of CoreDNS in github.com/openshift/coredns. Our fork will need to be rebased onto https://github.com/coredns/coredns/releases/tag/v1.8.1, which may involve some git fu. Refer to previous CoreDNS Rebase PR's for any pointers there.
CoreDNS v1.7 renamed some metrics that we use in our alerting rules. Make sure the alerting rules in https://github.com/openshift/cluster-dns-operator/blob/master/manifests/0000_90_dns-operator_03_prometheusrules.yaml are using the correct metrics names (and still work as intended).
We need to verify that no new CoreDNS dual stack features require any configuration changes or feature flags.
(All dual stack changes should just work once we rebase to coredns v1.8.1).
See https://github.com/coredns/coredns/pull/4339 .
We also need to verify that cluster DNS works for both v4 and v6 for a dual stack cluster IP service. (ie request via A and AAAA, make sure you get the desired response, and not just one or the other). A brief CI test on our dual stack metal CI might make the most sense here (KNI Might have a job like this already, need to investigate our options to add dual stack coverage to openshift/coredns).
Create a PR in openshift/cluster-ingress-operator to implement the PROXY protocol API.
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)?
Feature Overview
- This Section:* High-Level description of the feature ie: Executive Summary
- Note: A Feature is a capability or a well defined set of functionality that delivers business value. Features can include additions or changes to existing functionality. Features can easily span multiple teams, and multiple releases.
Goals
- This Section:* Provide high-level goal statement, providing user context and expected user outcome(s) for this feature
- …
Requirements
- This Section:* A list of specific needs or objectives that a Feature must deliver to satisfy the Feature.. Some requirements will be flagged as MVP. If an MVP gets shifted, the feature shifts. If a non MVP requirement slips, it does not shift the feature.
| Requirement | Notes | isMvp? |
|---|
| 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 |
(Optional) Use Cases
This Section:
- Main success scenarios - high-level user stories
- Alternate flow/scenarios - high-level user stories
- ...
Questions to answer…
- ...
Out of Scope
- …
Background, and strategic fit
This Section: What does the person writing code, testing, documenting need to know? What context can be provided to frame this feature.
Assumptions
- ...
Customer Considerations
- ...
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)?
The work on this story is dependent on following changes:
- Enhancement doc - https://github.com/openshift/enhancements/pull/577
- API change - https://github.com/openshift/api/pull/852
- Ingress operator changes - https://github.com/openshift/cluster-ingress-operator/pull/552
The console already supports custom routes on the operator config. With the new proposed CustomDomains API introduces a unified way how to stock install custom domains for routes, which both names and serving cert/keys, customers want to customise. From the console perspective those are:
- openshift-console / console
- openshift-console / downloads (CLI downloads)
The setup should be done on the Ingress config. There two new fields are introduced:
- ComponentRouteSpec - contains configuration of the for the custom domain(name, namespace, custom hostname, TLS secret reference)
- ComponentRouteStatus - contains status of the custom domain(condition, previous hostname, rbac needed to read the TLS secret, ...)
Console-operator will be only consuming the API and check for any changes. If a custom domain is set for either `console` or `downloads` route in the `openshift-console` namespace, console-operator will read the setup set a custom route accordingly. When a custom route will be setup for any of console's route, the default route wont be deleted, but instead it will updated so it redirects to the custom one. This is done because of two reasons:
- we want to prevent somebody from stealing the default hostname of both routes (console, downloads)
- we want to prevent users from having unusable bookmarks that are pointing to the default hostname
Console-operator will still need to support the CustomDomain API that is available on it's config.
Acceptance criteria:
- Console supports the new CustomDomains API for configuring a custom domain for both `console` and `downloads` routes
- Console falls back to the deprecated API in the console operator config if present
- Console supports the original default domains and redirects to the new ones
Questions:
- Which CustomDomain API takes precedens? Ingress config vs. Console-operator config. Can upgrade cause any issues?
Dump openshift/api godep to pickup new CustomDomain API for the Ingress config.
Implement console-operator changes to consume new CustomDomains API, based on the story details.
Feature Overview
This will be phase 1 of Internationalization of the OpenShift Console.
Phase 1 will include the following:
- UI based language Selector instead of using browser detection
- Externalize all hard coded strings in the client code including all OpenShift static plugins
- Admin Console
- Dev Console
- Serverless
- Pipelines
- CNV
- OCS
- CSO
- Localized Date\Time
- Setup all processes, infrastructure, and testing required
- We will start with support for Chinese and Japanese lang
Phase 1 will not include:
- Dynamically generated UI (Operator, OpenAPIV3Schema)
- Operators that surface informational messages may not have translations available
- Strings from non client code
- This may include items such as events surfaced from Kuberenetes, alerts, and error messages displayed to the user or in logs
- Localization of logging messages at any level is not in scope
- Any CLI
- Language support for left to right languages ie Arabic
Initial List of Languages to Support
---------- 4.7* ----------
- Japanese - Code: ja
- Chinese - Code: zh_CN, zh_TW
- 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 ----------
- Spanish: - Code: es_419, es
- German: - Code: de
- French - Code: fr
- Italian - Code: it
- Portuguese - Code: pt_BR
- Korean - Code: ko
- Hindi - Code: hi
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
- Dynamically generated UI (Operator, OpenAPIV3Schema)
- Operators that surface informational messages may not have translations available
- Strings from non client code
- This may include items such as events surfaced from Kuberenetes, alerts, and error messages displayed to the user or in logs
- Localization of logging messages at any level is not in scope
- Any CLI support
- 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 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):
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>
We have too many namespaces if we're loading them upfront. We should consolidate some of the files.
Consolidate namepsaces S-Z to reduce change size
Consolidate namepsaces E-I to reduce change size
Just do namespaces from A-D to reduce number of files being changed at once
Feature Overview
Openshift Sandboxed Containers provide the ability to add an additional layer of isolation through virtualization for many workloads. The main way to enable the use of katacontainers on an Openshift Cluster is by first installing the Operator (for more information about operator enablement check [1]).
Once the feature is enabled on the cluster, it just a matter of a one-liner YAML modification on the pod/deployment level to run the workload using katacontianers. That might sound easy for some, but for others who don't care about YAML they might want more abstractions on how to use katacontainers for their workloads.
This feature covers all the efforts required to integrate and present Kata in Openshift UI (console) to cater to all user personas.
Background, and strategic fit
To enable for users to adopt Kata as a runtime, it is important to make it easy to use. Adding hook-points in the UI with ease-of-use as a goal in mind is one way to bring in more users.
Goal(s)
The main goal of this feature is to make sure that:
- It is easy for users to find out how to use/enable Openshift Sandboxed Containers on their clusters (e.g., Getting started guide in the UI).
- Cluster-admins are able to differentiate between normal pods and Kata pods.
- Developers (application, CNF, ...) have an easy way to create Katacontiners (without peeking at YAMLs)
- Application End-users are able to collectively activate kata on their app packages/content (e.g., Helm, odo,...)
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 a 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)?
References
[1] https://issues.redhat.com/browse/KATA-429?jql=project %3D KATA AND issuetype %3D Feature
Goal
The grand goal is to improve the usability of Kata from Openshift UI. This EPIC aims to cover only a subset that would help:
- Make it easy to differentiate between native cluster runtime (e.g., runC) and kata.
- Enable Kata as a runtime without modifying YAMLs.
To use a different runtime e.g., Kata, the "runtimeClassName" will be set to the desired low-level runtime. Also please see [1]:
"RuntimeClassName refers to a RuntimeClass object in the node.k8s.io group, which should be used to run this pod. If no RuntimeClass resource matches the named class, the pod will not be run. If unset or empty, the "legacy" RuntimeClass will be used, which is an implicit class with an empty definition that uses the default runtime handler. More info: https://git.k8s.io/enhancements/keps/sig-node/runtime-class.md This is a beta feature as of Kubernetes v1.14.."
apiVersion: v1 kind: Pod metadata: name: nginx-runc spec: runtimeClassName: runC
The value of the runtime class cannot be changed on the pod level, but it can be changed on the deployment level
apiVersion: apps/v1
kind: Deployment
metadata:
name: sandboxed-nginx
spec:
replicas: 2
selector:
matchLabels:
app: sandboxed-nginx
template:
metadata:
labels:
app: sandboxed-nginx
spec:
runtimeClassName: kata. # ---> This can be changed
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
protocol: TCP
User-stories
- As a cluster-admin, I would like to be able to differentiate between a normal pod and a Katacontainer pod from the UI.
- As a developer, I would like to create katacontainers-based pods without dealing with YAML, i.e., from the UI.
- As a developer, I would like to switch my deployments to use Kata instead on runC (native).
Requirements
- Kata runtime MUST be viewable when checking running workloads.
- A checkbox or a similar method to create Katacontainers from the UI MUST be provided.
- The above two requirements MUST be tested.
References
[1] https://docs.openshift.com/container-platform/4.6/rest_api/workloads_apis/pod-core-v1.html
We should show the runtime class on workloads pages and add a badge to the heading in the case a workload uses Kata. A workload uses Kata if its pod template has `runtimeClassName` set to `kata`.
Acceptance Criteria:
- Kata runtime must be viewable when checking running workloads, including Pods, ReplicaSets, ReplicationControllers, StatefulSets, Deployments, and DeploymentConfigs.
- Automated test must be written to verify coverage
Andrew Ronaldson indicated that adding a "kata" badge in the heading would be too much noise around other heading badges (ContainerCreating, Failed, etc).
