Dashboard implementation - GSoC scoping

[mbarbero]

The goal is to implement a dashboard listing all Jenkins instances running in the Kubernetes cluster (similar to https://ci.eclipse.org) but with live data from the cluster (pod status, resource usage, Jenkins queue size etc...). The dashboard itself will run in the cluster. Server side implementation will preferably be in Java, while the dashboard client will preferably be implemented as a set of reusable React JS components. The dashboard will be composed of 2 apps with the following high level technical specs:

• Java app that queries the Kubernetes API server to list all Jenkins instances running in the cluster + queries the Jenkins instances to gather jenkins specific information (running version, queue length, ..) and exposed the gathered information with REST API (i.e. it's a facade pattern). Let's call it the "Jiro dashboard API".
  • One need to get all Kubernetes statefulsets with label org.eclipse.cbi.jiro/kind="master" (in all namespaces). This app will eventually run in the cluster, so credentials to connect to the API server will be the one from the service account of the pod running this App.
  • Various queried endpoints will be polled on a regular basis (e.g. every 10min).
  • the gathered information will be exposed with a couple of REST endpoints, e.g.:
    • /jenkins => return list of Jenkins instances with high level information (display name, project_id, status)
    • /jenkins/<project_id> => full details about the instance
  • The REST API will preferably be implemented following Eclipse Microprofile (https://microprofile.io) specs, e.g. with https://thorntail.io
  • No authentication is required
• reactJS app that queries the "Jiro dashboard API" and displays the various information in a clear and modern UI.
  • Each Jenkins instance will display the same kind of information, maybe with the ability to get more information on demand (e.g. with an expandable panel). React components should be defined and composed to properly encapsulate the various states
  • dependencies to 3rd-party libraries will be minimized (e.g. prefer Fetch API rather than jQuery AJAX dependencies).
  • the app will be served by a nginx server
• Those two apps will be containerized and deployed to the cluster.

The contribution are expected to be in the form of various PR. We can define 3 milestones, roughly matching the GSoC 3 terms:

1. dashboard API server with /jenkins endpoint only.
2. frontend app displaying list retrieved from /jenkins endpoints
3. /jenkins/<project_id> endpoint is implemented and the frontend app is expanded to display those information on demand.

[rohanjulka19]

[rohanjulka19]

Hi Mikael ,
We can use watch[1] in kuberentes api instead of polling what do you suggest ?

[1] https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes

[mbarbero]

Very good idea. Thanks!

…

On Thu, Mar 21, 2019 at 4:20 AM Rohan Julka ***@***.***> wrote: Hi Mikael , We can use watch[1] in kuberentes api instead of polling what do you suggest ? [1] https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAboEbxlmD3nVbXzGH7knd4L_x1uqTM8ks5vYvprgaJpZM4bhNWf> .