User Interface Design

[matankb]

Integration with Openshift

The repository for the main Openshift front-end UI is located at https://github.com/openshift/console. There are two different possible methods to connect Curator with Openshift.

1. Make the Curator UI a specific page in the Openshift UI.

This method would involve forking the Openshift UI respository and developing the Curator UI on top of the existing codebase. The Openshift UI is built with React, and consists of a wide range of existing pages for administrating and developing with Openshift. We can create a new page (or multiple pages, if necessary), within the existing Openshift UI repository, which would act as the Curator UI. Using this method, users would be able to log in to the same web app they already use for Openshift management and access Curator.

If we chose this method, we would need to ensure that our fork is kept in sync with the upstream Openshift UI repository. Once we have created a working product, we could potentially merge our new code in to upstream repository. Currently, the Curator UI is in a top-level directory in the operate-first/curator repository. If this method is chosen, it would likely need to become a separate repository.

Additionally, there is currently a page in the Openshift UI called "Monitoring", which appears to be accomplishing some of the same goals as Curator. This should be investigated.

2. Make the Curator UI as a separate web application.

Currently, the limited existing code for the Curator UI is set up as a separate React web application. This method would involve continuing to develop Curator UI as a separate web application, that is not explicitly connected to the main Openshift UI web application. Users would log in to the separate Curator web application with the same credentials that they use for Openshift. If this method is chosen, it would avoid potential complexities involved with integrating the UI into the existing Openshift repository.

User Interface Requirements

This section describes the basic requirements for the Curator user interface.

• Time Period Selector: An input to select the period of time which the UI will display data for, including both the frequency (day, week, or month; the user can select one or multiple), and the start and end dates.
• Data displays: The majority of the user interface will consist of tables which display the selected metrics. The metrics are are cpu, memory, and volume data at the cluster, pod, node and namespace level. There are a wide range of different ways to display this data. Some possible designs include:
  • When the user opens Curator and selects a time period and a specific area (either a namespace, node, pod, or cluster), it would display three interactive line charts for the CPU, memory, and volume over time. They could also plot multiple namespaces/nodes/pods/clusters on the same chart, in order to compare them.
  • When the user opens Curator, it would display a table of namespaces (the highest level), with their associated aggregate cpu, memory, and volume usage data for the given time period. The user would be able to click on each namespace to make the table display the nodes in that namespace; they could then click a node to display the pods, and click a pod to display the clusters. In this sample screenshot, the user has clicked on a namespace titled "Example Namespace", a node titled "Example Node', and a pod titled "Example Pod", and is now browsing the clusters in that pod.

┆Issue is synchronized with this Asana task by Unito