randy424/console

The user interface for the cluster management portion of open-cluster-management.

@stolostron/console

What is console?

The console provides the user interface for Red Hat Advanced Cluster Management (ACM) for Kubernetes and Red Hat MultiCluster Engine (MCE).

Go to the Contributing guide to learn how to get involved.

Prerequisites

• Node.js 20
• NPM 8

Active Release Branches

The same codebase is used to build images for Red Hat Advanced Cluster Management for Kubernetes (from release-* branches) and multicluster engine for Kubernetes (from backplane-* branches). The build system fast-forwards between branches to keep the content in sync. Pull requests should only be opened against the first branch in each line listed below. The arrow represents an automatic fast-forwarding of commits from one branch to the next.

main → release-2.12 → backplane-2.7
release-2.11 → backplane-2.6
release-2.10 → backplane-2.5
release-2.9 → backplane-2.4
release-2.8 → backplane-2.3
release-2.7 → backplane-2.2
release-2.6 → backplane-2.1
release-2.5
backplane-2.0 // cherry-pick from PRs against release-2.5
release-2.4

Core Dependencies - Release Branch Mapping

A number of the core NPM package dependencies are published from other repositories. To allow development of new features in these projects, branches are created each time a new release is started.

console branch	patternfly-labs/react-form-wizard	stolostron/react-data-view	stolostron/ui-components	stolostron/temptifly
main release-2.12 backplane-2.7	main	main	N/A	N/A
release-2.11 backplane-2.6	v1.29.z	v1.14.z	N/A	N/A
release-2.10 backplane-2.5	v1.27.z	v1.13.z	N/A	N/A
release-2.9 backplane-2.4	v1.26.z	v1.12.z	N/A	N/A
release-2.8 backplane-2.3	v1.23.z	v1.10.z	N/A	N/A
release-2.7 backplane-2.2	v1.13.z	v1.4.z	N/A	N/A
release-2.6 backplane-2.1	v1.8.z	v1.0.z	N/A	N/A
release-2.5 backplane-2.0	v1.7.z	N/A	v1.69.z	2.5
release-2.4	N/A	N/A	v1.25.z	2.4
release-2.3	N/A	N/A	v0.180.z	2.3
release-2.2	N/A	N/A	No branch; uses 0.1.214	2.2

Running

1. Clone repository

2. Install dependencies

   npm ci
   

3. Setup environment

   You need:

   • to be connected to a OpenShift 4.x.x cluster
   • to have Red Hat Advanced Cluster Management or multicluster engine for Kubernetes installed on the cluster

   npm run setup
   

   This will create a .env file in the backend directory containing environment variables.

4. Start the development services

   npm start
   

   This will start the frontend and the backend in parallel. (It may take up to 30 seconds for the UI to appear)

   NOTE: If a port conflict appears with port 4000, you can override it by exporting BACKEND_PORT with a new value like 4001 and re-running the setup and start commands

Running as an OpenShift console plugin-in

See Dynamic Plugins - Development

Architecture

See ARCHITECTURE.md

Chrome

To develop with self signed certificates goto chrome://flags/and enable

• Allow invalid certificates for resources loaded from localhost.
• Insecure origins treated as secure.
  • http://localhost

Authentication

Frontend has a cookie acm-access-token-cookie that contains the user's token.

If the backend responds with a 401 Unauthorized the frontend starts an OAuth flow to authorize with the cluster.

1. Frontend redirects to the backend /login endpoint.
2. Backend redirects to the cluster /authorize endpoint.
3. Cluster OAuth redirects back to the backend /login/callback endpoint.
4. Backend redirects to the frontend and sets the acm-access-token-cookie.

Optional Features

In some cases there are development preview (Dev Preview) features or technical preview (Tech Preview) features that can optionally be enabled and used in the product. These features are enabled by updating the console-config configmap in the installation namepsace (default: open-cluster-management). The following features are available:

Single node OpenShift

Enabling this feature will allow the user to create a cluster that only contains a single control plane node. This option is only available for providers AWS, Azure, GCP, OpenStack and VMware when the OpenShift release image is version 4.8 or higher.

References

console is an add-on for the open-cluster-management community. For more information, visit: open-cluster-management.io

console's Issues

Migrate managedCluster tests

Refactor and migrate tests located in "clc-ui-e2e/cypress/tests/clusters/managedClusters".

Refactoring may not be necessary for every test, but to meet our maintainability goals, we should consider refactoring where ever it's needed.

define process on conversion from JS to TS

What is your process when converting a suite or helper functions to TS? what do you tackle first and what do we need to watch out for specially in this repo?

we don't need to convert everything now - there is a lot - but having a guideline (that can iteratively improved) for collaborators in the future will be helpful

Containerize tests for portability

Migrate credentials tests

Refactor and migrate tests in "clc-ui-e2e/cypress/tests/credentials".

Refactoring may not be necessary for every test, but to meet our maintainability goals, we should consider refactoring where ever it's needed.

Cypress MVP

At some point we will want to demo our Cypress solution to the console team and to the wider org.
To do so efficiently we will outline a "MVP" consisting of a few must-have requirements to get up and running:

1. Deliver an e2e testing suite that supports the most recent, stable, Cypress.
2. The testing suite should be geared towards maintainability, so we want to have strong confidence in our high-level structure for helper components, fixtures, and test suites. Components should be written and organized as to avoid duplication and enable ease of use for subsequent contributors. Documentation for code and organization should be included where necessary or useful.
3. To satisfy this epic, testing will cover a cross-section of the product (Credential & Cluster as our MVP?). In a subsequent epic, we will outline goals for migrating/refactoring the remainder of clc-ui-e2e.
4. Ensure the test suite is enabled for local testing and for production level testing in Prow. Prepare the necessary scaffolding for this suite to run automatically, (via maybe github actions) twice a day.
5. Develop a presentation that outlines how QE and Console will interact with the repo over the course of a train, and how it solves problems outlined in our Rework Doc

Design a highly approachable directory structure.

To meet our maintainability goals it's critical that our directory structure satisfies a few requirements:

1. The structure should leverage Cypress 12's new standards for the preprocessor API (for example, by default, Cypress will execute certain code ahead of the tests. Specifically, this will be the cypress/support/e2e.js or cypress/support/component.js files). This applies to support files but also to the new config structure.

2. We should respect deprecated conventions/preprocessor APIs (plugins directory, cypress/index.js, etc.). Files that leverage older api conventions should be migrated to adopt the more recent one.

3. We must access current directory naming conventions in clc-ui-e2e, do they make sense, are they helpful? We should also consolidate helper functions, custom cypress functions, and reusable behavior in the code, where possible, and move them to the appropriate top-level directory (this should be the support directory). Let's limit the scope of this issue to the functionality required for our MVP.

Differentiate between local/remote cluster testing.

testing against local vs remote testing should be painless and an easy toggle/switch of some kind

see PR https://github.com/Randy424/console/pull/15/files#diff-6c107e2390c5ad84e123f3be09d7b91ba35de8f8cc550d1f358c75806df47645L39

Define required test spec format for test reporting

Running tests via tags

we want to be able to run tests based on tags

1. how do i run all the suites with @create?
2. how do i run all tests that have the @create suite tag and only the "aws" tag?