strimzi / strimzi-ui

Strimzi UI

Run Apache Kafka on Kubernetes and OpenShift

Strimzi provides a way to run an Apache Kafka® cluster on Kubernetes or OpenShift in various deployment configurations. See our website for more details about the project.

Quick Starts

To get up and running quickly, check our Quick Start for Minikube, OKD (OpenShift Origin) and Kubernetes Kind.

Documentation

Documentation for the current main branch as well as all releases can be found on our website.

Roadmap

The roadmap of the Strimzi Operator project is maintained as GitHub Project.

Getting help

If you encounter any issues while using Strimzi, you can get help using:

• #strimzi channel on CNCF Slack
• Strimzi Users mailing list
• GitHub Discussions

Strimzi Community Meetings

You can join our regular community meetings:

• Thursday 8:00 AM UTC (every 4 weeks starting from 4th June 2020) - convert to your timezone
• Thursday 4:00 PM UTC (every 4 weeks starting from 18th June 2020) - convert to your timezone

Resources:

• Meeting minutes, agenda and Zoom link
• Recordings
• Calendar (Subscribe to the calendar)

Contributing

You can contribute by:

• Raising any issues you find using Strimzi
• Fixing issues by opening Pull Requests
• Improving documentation
• Talking about Strimzi

All bugs, tasks or enhancements are tracked as GitHub issues. Issues which might be a good start for new contributors are marked with "good-start" label.

The Dev guide describes how to build Strimzi. Before submitting a patch, please make sure to understand, how to test your changes before opening a PR Test guide.

The Documentation Contributor Guide describes how to contribute to Strimzi documentation.

If you want to get in touch with us first before contributing, you can use:

• #strimzi channel on CNCF Slack
• Strimzi Dev mailing list

License

Strimzi is licensed under the Apache License, Version 2.0

Container signatures

From the 0.38.0 release, Strimzi containers are signed using the cosign tool. Strimzi currently does not use the keyless signing and the transparency log. To verify the container, you can copy the following public key into a file:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAET3OleLR7h0JqatY2KkECXhA9ZAkC
TRnbE23Wb5AzJPnpevvQ1QUEQQ5h/I4GobB7/jkGfqYkt6Ct5WOU2cc6HQ==
-----END PUBLIC KEY-----

And use it to verify the signature:

cosign verify --key strimzi.pub quay.io/strimzi/operator:latest --insecure-ignore-tlog=true

Software Bill of Materials (SBOM)

From the 0.38.0 release, Strimzi publishes the software bill of materials (SBOM) of our containers. The SBOMs are published as an archive with SPDX-JSON and Syft-Table formats signed using cosign. For releases, they are also pushed into the container registry. To verify the SBOM signatures, please use the Strimzi public key:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAET3OleLR7h0JqatY2KkECXhA9ZAkC
TRnbE23Wb5AzJPnpevvQ1QUEQQ5h/I4GobB7/jkGfqYkt6Ct5WOU2cc6HQ==
-----END PUBLIC KEY-----

You can use it to verify the signature of the SBOM files with the following command:

cosign verify-blob --key cosign.pub --bundle <SBOM-file>.bundle --insecure-ignore-tlog=true <SBOM-file>

---

Strimzi is a Cloud Native Computing Foundation incubating project.

strimzi-ui's Issues

Architecture (post proposal): Security

To discuss/define:

• How authentication, authorization and sessions are handled in the UI
• CRUD model mentioned in #12 (comment) and how this maps to authorization/roles

Architecture: Configuration and feature flagging

Follow on from #6

Investigate and add to the Architecture document from #6 the UI's approach (for both client and server) for feature flagging, and the providing/use of configuration to the UI.

Architecture (post proposal): Strimzi integration

• Work with the @strimzi/maintainers to how the UI will be deployed (alongside Strimzi-admin) by the operator
• Document approach/appriate implementation details in the UI repo
• Make updates (if any) to the current dockerfile to integrate

Architecture: Storybook

Follow on from #6

Add documentation to the Architecture document created iin #6 to describe the purpose of/set requirements around the use of Storybook for component development in the Strimzi-ui.

Architecture: Mock admin server

Follow on from #6

Add to the architecture document created under #6 details of the Mock admin server - including:

• how it operates/is implemented (route controller model?)
• how it is configured (including dynamic values if possible - for the purpose of testing)

Entity Model

Implement helper code and constants to enable the Entity model described here: https://github.com/strimzi/strimzi-ui/blob/master/docs/Architecture.md#entity-model

• Requires testing issues to be completed

Add GraphQL Client for transport layer

Implementation from details outlined in #38.

Implement logging in client

Issue to implement the client-side section of #41

A11y testing and support

The Strimzi-ui should be fully accessible (a11y) from day 0. This issue is to investigate what tooling we can use to catch a11y issues early/make sure the UI is accessible to any user of it.

As per the proposal (strimzi/proposals#6), we will target the superset of US Section 508 and WCAG21AA rulesets.

Architecture: Logging and Servicability

Issue to document how logging will work in both the client and server of the Strimzi UI, thus enabling the ability to maintain and debug the UI as and when required.

Suggestions:

• On the server side use a logging library to write to STDOUT
• On the client side, set up a/use an existing Websocket to send log messages to the server, which then appends them to STDOUT
  • These log messages from the client are enabled/disabled via query parameter in the URL. This is detected by a Logging Hook, which provides a logging calbback used in components/code on the client side, which if enabled sends the content over the web socket.
• Stretch - have some sort of ID to link/correlate server actions and client actions (eg a request for data can be tracked from initiation to response to render)

Update commitlint to version 11.0.0

We currently use version 9.1.0 which has a bug where it can't correctly identify if a commit includes a Signed-off-by line at the end of the commit.

This has now been fixed through this issue conventional-changelog/commitlint#1809

Version 11.0.0 is currently the latest version and also includes this fix

Provide linting documentation

Issue to write up and provide linting documentation for Strimzi-ui. This documentat should cover what rules are in place, what tools are used to enforce it, and how it is configured.

Update code style doc to mention js docs

Anything defining a contract such as types, interfaces, and props, should have a relevant JSDoc to go with it

CI checks out master branch on PR instead of PR branch

With the move to pull_request_target as the github workflow trigger, it's now checking out master in the CI pipeline instead of the PR branch

Introspection Context

Issue to implement an Introspection Context, as described in https://github.com/strimzi/strimzi-ui/blob/master/docs/Architecture.md#introspection and https://github.com/strimzi/strimzi-ui/tree/master/client/Contexts/Introspect

• Requires GQL library ( #38 ), testing issues to be completed

Implement testing framework

Following the work from #7, the testing strategy outlined in the documentation needs to be implemented.

Provide Code style/contribution documentation

Issue to write up and provide documentation around the code style used and contribution in this codebase. This document should cover the rules, reasons why we enforce them, and acts as a reference for use in PRs if one of the below rules/style choices are not followed. This document should include (but not be limited to):

• Linting rules applied (using the framework/tools put together in #3)
• Implementation decisions/expectations, including:
  • READMEs being provided for each area of code to explain context/functionality of that area
  • READMEs for all components/as a part of the first contribution
  • TDD, with a focus on user (developer or end user) behaviour/usage (cover the reasons why - more detail to be provided in a Test document)
  • React functional components only using Hooks
  • Context used for state management
  • Storybook stories for all components
  • The Element/Group/Panel/Bootstrap component convention (cover the reasons why - more detail to be provided in an architecture document - #6 ) - including the expected files per component type
  • Use of sensible/contextual conventions
• Methodologies to apply (eg BEM, namespacing for styling), and how these are enforced

Implement a continuous integration pipeline

• This is outlined in the work from #8
• Should be the last thing done after all other set-up has been completed

Provide CI and automation documentation

Issue to write up and provide documentation around what CI and automation is used in Strimzi-ui.

This should cover:

• What tool(s) are used to drive CI / what pieces of automation
  • Nice to haves; dependabot (automated dependency management), GitHub actions (for PRs - ie checks to run, issue management etc)
• How they are configured

UI mockups /screenshots

It will be great to see some screenshots of what is being developed. If not those, even UI mockups will be great to see on the readme.

Provide UI Architecture documentation

Issue to write up and provide architecture and codebase goals documentation for Strimzi-ui. The scope of this issue is to cover the UI codebase implementation, and then how it integrates into the wider Strimzi once strimzi/proposals#6 has been agreed.

This documentation should cover/include in the first pass:

• How the swappable view layer works:
  • How this is set up, and how to add other view layer implementations
  • How to use React hooks to calculate/provide business logic to view layers
• Code structure
  • That all code send to the browser is in a client directory
    • The Element, Group, Panel and Bootstrap component differentiation in scope, implementation and test
  • That all code which implements the UI server is in a server directory
  • That utility code is in a utils directory, for use in both the client and server directories
• Utilities/tools used to enable development and deployment use cases, such as:
  • Storybook
  • Translation/Feature flagging/configuration approaches
  • A mock implementation of the proposed backend for use in test cases and day to day development
• A topology diagram, showing how the client, UI server, and proposed backend interact when deployed in production
• A topology diagram, showing how the client, UI server, and mock backend interact when under test/development
• Routing/navigation approach, and tools used
• Metadata driven approach
• Configuration/Feature Flagging strategy

It should also add general goals/objectives for the codebase. As per the proposal I would suggest:

• Focusing on the user, be them developer or end user, at all times
• Adopting a cloud like CICD development model: lots of small and often changes, appropriatley flagged, with the master branch being shippable at any time
• Use automation as much as possible to maintain a CICD model - things like automated dependency updates, issue management etc
• Make the codebase as approachable as possible through the use of consistent style, and supporting documentation

Items to add later to this document include (seperate issues to cover):

• Backend implementation/code structure (pending proposal agreement)
• Security (pending proposal agreement)
• High level client/server diagrams showing how the implemented modules/components interact
• Wider Strimzi integration
  • deployment
  • api versioning

Implement a base UI and mock admin server

Issue to implement the UI and Mock Admin server described in #16 / #15

Enable Module Federation (Upgrade to Webpack 5)

We intend to use Webpack Module Federation to build Red Hat product UIs from Strimzi UI.

In order to do this we will need to enable Module Federation in Strimzi UI, which will involve:

• Add this to the relevant architecture documentation
• Upgrading Webpack to the latest v5 release (Module Federation was added in Webpack 5)
• Upgrading all Webpack loaders & plugins to the latest version (this will ensure they are compatible with Webpack 5)
• Add the module federation plugin to the webpack config, and declare source files we want to expose
• Add shared dependencies (react, react-dom) as shared dependencies
• Add default exports to each source file we want to expose (with the default export pointing at the component we are exporting)

This also has an impact on how we design our React components as we need to start designing them for reuse in unknown situations, not just use within in the strimzi-ui. Designing components for reuse via module federation is no different to designing them for reuse via npm dependency management.

A few component design rules that will make reuse much easier are:

• create "pages" that wrap components. For each view that we want to create, build the component separately from the page, allowing the the component to be reused. A page might have titles, padding, layout etc. The component is the actual interaction.
• create "dumb" components that are wrapped by "smart" components (this is also very useful for mocking data for testing, storybook etc.). Here for each component we create we pass in any data that is needed using props, rather than directly accessing it. This allows the data sources to be altered in various ways by the reusing UI. Smart components are often pages as well.
• use callbacks to handle transitions to/from views in dumb components. In other words don't navigate using history but instead pass a callback in as a prop. This allows the component to be reused in a different setting.
• make components more granular. Don't build the entire view in a single component - split it up to allow reuse.

Configure Jest for testing browser/react code

All generated content (test output, built code) to be located in one directory

As per titile.

As more code has been contributed, the ammount of generated assets (code coverage, test output etc) has also grown. At the moment, this output is spread across multiple directories - generated, dist, js, e2e/failure_output, .out and coverage. This is a little messy, but has caused a bloat of the ignored directories in linting configuration, eg

strimzi-ui/linting/license-check-and-add.config.json

Line 10 in 0f6428c

"./generated/**",

This issue is to co locate these directories, tidy the linting configuration, and any references to automation which uses these.

Use Typescript over Javascript

Recent discussions have mentioned the use of Typescript over Javascript. This issue is to track that discussion, best practise, and actions to update the proposal/repo based on those discussions.

Provide Build documentation

Issue to write up and provide build documentation for Strimzi-ui. At first this will detail just how the UI code will be built and developed, but when agreed, will be updated to also detail how the UI is built/packaged into Strimzi itself.

Commentor action fails to add comment when PR is from a fork

As a part of #35 a GitHub action was added to add a comment to a PR with details such as bundle sizes, test coverage etc. This works (when tested on your own fork), but fails on the Strimzi-ui repo with:

HttpError: Resource not accessible by integration

From some quick searching around, the error implies some permissions are missing, or this action will never work (as the request is from a fork) - actions/labeler#12 (comment)

This issue is to find out if this is fixable, and if not, alternatives to get the information currently not presented in the PR

Update/Remove git commit hash from end of gh-actions comment

Now that the workflow trigger has changed to pull_request_target, the commit that triggered the workflow is the commit to enable the comment to work. So, this needs to be updated to show the PR commit that triggered the workflow if possible and removed if not.

Implement `mockapi` module

Issue to cover the implementation of a mock version of strimzi-admin.

Implementation idea: Use GitHub submodule to get the Strimzi-admin graphql schema, which is used by the mock admin server to generate mock data for development.

Selective test coverage investigation.

How do we want to figure out meaningful code coverage by checking that lines have actually been covered in a meaningful way?

@JQrdan mentioned Jest has an option for this - this issue is to explore it, and if we can get benefit from it.

Implement server-side logging

Issue to implement the server-side section of #41

Revisit/tidy up docs

There is quite a lot of documentation in the repo, which reference each other. Some documents are monaliths.

This issue is to review the documentation, and take any actions (break files down etc) to make the documentation more inutive to find/consume.

Architecture: dependency approach

This issue is to add to the Architecture document a section around npm dependency mangement, and that we could (and I think should) place dependencies in either dependencies or devDependencies with care.

In my opinion, any dependency which is used directly, or is responsible for generating/producing code which is built and used at runtime should be present dependencies . This means in the case where a security issue is found, we can quickly identify if it effects the 'shipped'/built code. This can be then leverdged via tools like npm audit to provide further details on just the production dependencies for instance.

Theme switching

A pretty common (and nice to have) feature of modern UI is theme switching - i.e light mode, dark mode.

There has not been a requirement to support this yet in the Strimzi-ui, but is a feature that if thought about early can be more easily implemented later.

This issue is to understand the theming approach of Patternfly and Carbon, what they require, and how they could be abstracted.

Architecture: routing, navigation, introspection

Follow on from #6

Investigate and propose an approach for routing and navigation, and how GQL introspection can dynamically enable/disable routes in the UI

Architecture (post proposal): Transport layer

• The UI uses GraphQL - why, and what libraries are used to support this?
• Define/document the transport (WS, HTTP etc) used by the UI, and what they are used for

UI Bootstrap UX

Issue to cover the discussion and development of UX of the timeframe where the UI bootstraps itself.

From a UX POV, we will need to cover/handle the loading (and error states) of three data requests/result handling. These requests will be for:

• Authorization status (if security enabled)
• Introspection (to discover backend capability)
• Configuration

In a golden path scenario, I imagine this will be a loading spinner (or similar) while the data is fetched/processed. I would expect all 3 calls to be excuted in paralell, and be reasonibly quick to complete.

What I am unsure of is how an error would be surfaced, and if a retry button (for example) would be of use.

As a part of the discussion, the defintion of a set of Gherkin based behaviours should be identified, which will be used as the base for acceptance testing.

This discussion may also identify other UI components required to enable these flows. These should be discussed/designed in their own issues.

Update versions of Node/NPM used

As per titile. Update the repo and docs to use the latest LTS version of node/npm.

Provide UI Test documentation

Issue to write up and provide test documentation for Strimzi-ui.

This should cover:

• The types of testing required on areas of the codebase
  • I would suggest we aim for 100% code coverage as a minimum from day 0 - which should be checked/achieved by running tests on just the area in question
• Tools used for testing and why
  • Given piror discussion, would suggest Jest as a test runner/framework, React testing library
• How accesibility is tested, and accessible status maintained
• Updating existing documentation to show how/why these tools/approaches are used/how and where things should be tested

Initially this will cover the UI codebase only, but once we integrate the UI with Strimzi, it should also cover how these integrations are tested (eg via system test)

Login UX

Issue to cover the discussion and development of UX around Login (https://github.com/strimzi/proposals/blob/master/010-ui-and-admin-server-security.md)

• For no security or Oauth based flows no screen will need to be presented as it will be handled externally/not needed. However, some UX to confirm this may be worth exploring
• For Scram based logins, a username and password (with error states)

As a part of the discussion, the defintion of a set of Gherkin based behaviours should be identified, which will be used as the base for acceptance testing.

This discussion may also identify other UI components required to enable these flows. These should be discussed/designed in their own issues.

Modify `Build.md` -update endpoint command to run build

• Update the command in readMe to run UI build server

NPM lint scripts cannot be run independently without providing a directory

At the moment, the lint script is responsible for providing the directory (.). But, each script should provide this themselves so that they can be run individually

Run E2Es via action cron job, not PR

Issue to discuss (and implement if we agree) an action which runs E2Es nightly, which then raises and issue with failure details and commits which have been added since the last pass.

There are wider ramifications of the change - broken use cases in master - which need thought/mitigation.

Login, Loading, Error and Edge pages

This issue is to cover the discussion and design of the UX for the following pages/flows:

• Login (https://github.com/strimzi/proposals/blob/master/010-ui-and-admin-server-security.md)
  • For no security or Oauth based flows no screen will need to be presented as it will be handled externally/not needed. However, some UX to confirm this may be worth exploring
  • For Scram based logins, a username and password (with error states)
• Edge/Error pages described/identified here: https://github.com/strimzi/strimzi-ui/tree/master/client/Pages#current-pages
• UI wide error and loading states (while bootstrapping, etc)

As a part of the discussion, the defintion of a set of Gherkin based behaviours should be identified, which will be used as the base for acceptance testing.

This discussion may also identify other UI components required to enable these flows. These should be discussed/designed in their own issues.

Architecture: UI Server

Issue to define how the UI server is constructured in the Architecture document defined in #6

Topics (listing) page

This issue is to cover the discussion and design of the UX for the Topics listing page.

As a part of the discussion, the defintion of a set of Gherkin based behaviours should be identified, which will be used as the base for acceptance testing. The example given in the UI proposal is:

Scenario: Seeing all available topics:

Given I am a user of the UI
When I navigate to the topic listing
Then see all topics in my Kafka cluster

Scenario: Viewing a specific topic (when it exists in the cluster):
Given I am a user of the UI
When I navigate to the topic listing
And I filter for topic 'SampleTopic'
Then I see topic 'SampleTopic' in the topic list
And Topic 'SampleTopic' has '3' partitions and '2' replicas

Scenario: Viewing a specific topic (when it does not exist in the cluster):
Given I am a user of the UI
When I navigate to the topic listing
And I filter for topic 'SampleTopic'
Then I am told topic 'SampleTopic' does not exist in the cluster

A Carbon mockup of this, (again from the proposal) is as follows:

This discussion may also identify other UI components required to enable these flows. These should be discussed/designed in their own issues.

Navigation Component

Issue to implement the Navigation Bootstrap component described in https://github.com/strimzi/strimzi-ui/blob/master/docs/Architecture.md#routing-and-navigation / https://github.com/strimzi/strimzi-ui/blob/master/client/Bootstrap/Navigation/README.md

• Requires Introspection, Feature flagging and testing issues to be completed

Translation tooling/approach

The UI should be fully translatable from day 0. This issue is to look into either writing our own translation tooling or using a 3rd party library, and writing supporting documentation to how it works/should be used across the Strimzi-ui

Investigate: Open Tracing - https://opentracing.io

Open Tracing - https://opentracing.io - is a mechanism to trace a request from start to end. Could this be of value for the Strimzi UI (and the wider Strimzi)?

This issue is to look into this further, and if we want to persue it further. Potentially gets interesting with websocket communication.