Kubernetes Access Screen Master Ticket

[awly]

Goal

1. Create Kubernetes Access Screen
2. Get familiar with naming scheme for components and directory
3. Get familiar with how directory's are structured
4. Get familiar with using mocks and how to create storybook and understand different story states
5. Understand why we use custom hooks to isolate data for easier storybooking and testing
6. Get familiar in how we test (snapshot vs unit)
7. Understand the difference between webapps and webapps.e and know how to update enterprise submodules e-ref

How to get started

1. Read this entire issue
2. Create seperate PRs for each issue in order. Each issue will build on previous issues:
   • Table: [Kb Access 1] Table webapps#274
   • Table States: [Kb Access 2] Table's Attempt States webapps#275
   • Define database route, endpoint, and service: [Kb Access 3] Define route, endpoint, and service webapps#283
   • Define custom hook, register feature, update Main.story: [Kb Access 4] Define custom hook, register feature, update Main.story webapps#285
   • Add view doc btn and for each table row, add connect btn and popup dialogue: [Kb Access 5] Add Buttons and Popup Dialogue webapps#286

Design Images

Most images I posted on issues are just examples. The design should be the same, but the data displayed will be different. Normally we get design mocks from our designer, but it wasn't required b/c it will look the same as other other similar views like our Servers (aka Nodes) and Apps.

Open-source vs Enterprise

We have two webapps repo: Open-source (webapps) and Enterprise (webapps.e). Enterprise is included as a submodule in our OS repo (as show in image below). The webapps.e @ 5240310 says the enterprise webapps is currently pointing to commit 5240310 (which is the latest commit in webapps.e master). Whenever we make commits to the Enterprise repo, we have to update the reference this submodule is pointing to.

Directory Structure

This is how our directory is usually structured for most features (and what will look like for you). Note that capitalization's matter. Uppercase for components directory and components itself and lowercase for everything else.

- teleport/ (folder that contains all Teleport OSS codes)
  - src/ (folder that contains all the codes (components, services, stores))
    - services/ (folder that contains all the feature related services)
       - kube/ (folder that contains kubernetes related things)
           - kube.ts (contains api calls)
           - kube.test.ts (test response values are sanitized and formatted the way you expected)
           - make.ts (contains methods that sanitizes/processes/formats response values)
           - types.ts (contains objects shape)
           - index.ts (exports kube.ts and types)
    - Kube/ (folder that contains all kubernetes related components and mocked data)
       - Kube.tsx (the root component that will present the headers, buttons, dialogues, and table)
       - Kube.story.tsx (story that can be viewed in storybook, most common story states are `Loaded`, `Processing`, `Failed`)
       - Kube.story.test.tsx (snapshot of rendered storybook states (mostly `Loaded` and `Empty`)
       - index.ts (exports the root component)
       - KubeList/ (folder that will contain table related components)
           - KubeList.tsx (the table component)
           - index.ts (exports the table)
       - KubeAdd/ (folder that will contain dialogue related components)
           - KubeAdd.tsx (the dialogue component)
           - KubeAdd.story.tsx
           - KubeAdd.story.test.tsx (snapshot rendered states)
           - index.ts (exports the dialogue)
       - ButtonAdd/ (folder that will contain button component)
           - ButtonAdd.tsx (the button component)
           - ButtonAdd.story.tsx (showcase different states)
           - ButtonAdd.story.test.tsx (snapshot rendered state)
           - index.ts (exports the button)
       - fixtures/
           - index.ts (fixture indexes are just files that contains mocks that are exported)

References

Because the design's are the same, the code will be very similar to existing components, which can be used as reference to help you create your components. When you look up these directories/components, note the directory path, b/c some components can be from the gravity directory that have the same names. gravity is obsolete and outdated and is just there to be used as extra examples.

References for Table, Add Button, and Popup Dialogue

Nodes (aka Servers) is probably the closest in similarity in what you will create for table and dialogue:
Nodes: https://github.com/gravitational/webapps/tree/master/packages/teleport/src/Nodes
NodesList: https://github.com/gravitational/webapps/tree/master/packages/teleport/src/components/NodeList (The components directory contains components that can be shared between different components, NodeList is used within DocumentNodes and Node components, otherwise child components will be contained within their parent directory).

Apps is mostly as a second example to help you with creating the dialogue and button component:
Apps: https://github.com/gravitational/webapps/tree/master/packages/teleport/src/Apps

References for defining api endpoints and app routes

Routings and endpoints are defined in our config.ts file: https://github.com/gravitational/webapps/blob/master/packages/teleport/src/config.ts

Since kube listing is cluster specific, routing/ api endpoint will be very similar to how we define nodes and apps. The naming convention should also be similar:
App route: https://github.com/gravitational/webapps/blob/master/packages/teleport/src/config.ts#L42
App route getter: https://github.com/gravitational/webapps/blob/master/packages/teleport/src/config.ts#L171

App api endpoint: https://github.com/gravitational/webapps/blob/master/packages/teleport/src/config.ts#L79
App api endpoint getter: https://github.com/gravitational/webapps/blob/master/packages/teleport/src/config.ts#L255

References for creating a service file

Files inside services directory mostly contain files that are named after features and contains its related api calls, sanitizing/processing of response values, and typing the response value object. Service workflow follows the most up to date conventions (ie: defining service as a class and testing): https://github.com/gravitational/webapps.e/tree/master/teleport/src/services/workflow

The service is then instantiated in teleportContext.tsx file like so: https://github.com/gravitational/webapps/blob/master/packages/teleport/src/teleportContext.tsx#L41

Reference for registering a feature to sidenav

Any Open-source feature will also be in Enterprise and will be similar to how we register Nodes feature.

First need to set access perms:
https://github.com/gravitational/webapps/blob/master/packages/teleport/src/services/user/makeAcl.ts#L32

Features first needs to be defined in our OS features.ts file: https://github.com/gravitational/webapps/blob/master/packages/teleport/src/features.ts#L174

Then we need to register this feature to both OS and Enterprise in features.ts:
OSS: https://github.com/gravitational/webapps/blob/master/packages/teleport/src/features.ts#L381
Enterprise: https://github.com/gravitational/webapps.e/blob/master/teleport/src/features.ts#L96

References for updating Main.story.tsx

We have a story that renders a dashboard called Main.story (doesn't have all the features). We can use this component to test our component that uses custom hooks. Hooks contain dependencies that we can mock (contexts and api endpoints) inside Main.story. Workflow features has good examples:

Mocking services: https://github.com/gravitational/webapps.e/blob/master/teleport/src/Workflow/fixtures/index.ts#L99
Instantiating the mocked service: https://github.com/gravitational/webapps.e/blob/master/teleport/src/Main/Main.story.tsx#L59

[stevenGravy]

nice to have:

• navigating k8s objects
• open k8s console
• compare potential features to tools like rancher UI for a cluster.

[alex-kovoy]

Lets add a table with the columns matching the tsh output.