https://github.com/openshift/monitoring-plugin

Source: https://docs.openshift.com/container-platform/4.10/monitoring/monitoring-overview.html

I experimented a bit more and discussed more on that other thread. To summarize, currently we have two ways to test the console monitoring pages locally. If you are working on the monitoring-plugin codebase:

1. cd to monitoring-plugin root dir
2. Run yarn start in one terminal
3. Start docker
4. Run yarn start-console in a second terminal

1. cd to monitoring-plugin root dir
2. Run yarn start in one terminal
3. cd to console root dir
4. Run ./bin/bridge -plugins "monitoring-plugin=http://localhost:9001/"
   

In either case, the console will then be running locally at http://localhost:9000/ For our team, the first method is normally better because compile times are much faster. For the console team, currently the second method is the most convenient. It would be good to streamline this, but not sure how best to do that.

Alternatively, use a docker image of the monitoring plugin and point the bridge there.

Redux

Figure 1. Files used to dispatch/update information in the store.

1. Initiate dispatch from component. The component is manipulating an array so we need to pass the index to specify which index to update.
2. This is the file that declares available actions.
3. The definition of the action.
4. The store that holds the 'queryBrowser' global state. The 'queryBrowser' object doesn't have a strictly defined model/schema so you can dynamically add more attributes.

Figure 2. Files used to observe information in the store.

1. Observe the store by using observe.getIn[]. The is drilling into an object to extract a specific value in this case observe.getIn[['queryBrowser', 'queries', index, 'isEnabled']] means we're drilling into this object queryBrowser: { queries: [{isEnabled: boolean}] } to get the boolean value.
2. This is the object in the store we're observing.