Paginate the discover panel to only display a required number of pods at a time #496

phantomjinx · 2024-07-16T12:24:26Z

Rather than displaying all pods found in the cluster that contain a jolokia port (which could be 100s!), only return a limited set, where the limit is selected by the user. Support the ability to then fetch the next set of pods while keeping track of the previous set (not the actual pods) so that the user can re-fetch the previous pods if required. At any time only the finite set of pods that the user has specified should be resident in client memory.

…tio#496) * In order to paginate results, kubernetes uses 'limit' to limit the request and then returns a reference as a 'continue' property. By including the latter in the next query then next set of results can be obtained (see https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#list-pod-v1-core) * globals.ts * Modifies KubeObjectList to support the optional properties of limit and continue defined in the KLimitMetadata type * Adds a PagingMetadata class for keeping track of paging references and the current index of the query, ie. <prev-ref> <index> <next-ref> * PagingMetadata support incremting and decrementing the current index in order to enable the moving to a previous or next set of results. * Kubernetes-service.ts * Refactored to support adding metadata limit to the watching of pods * Synchronises the pod watching code for both Namespace and Cluster config into a single function (initNamespaceClient). * Adds the namespace limit (nsLimit) to the pod options to be attached to the uri * If there is a continue reference for the current project/namespace then it too is added to the options for appending to the path uri * Watching the pods returns a result metadata as well as the pods which contains the podsRemaining property and a continue reference * The podRemaining property must be added to the 'current' paging metadata whilst the continueRef must be added to the 'next' paging metadata * Holds pods by project rather than just pods so that the project name can be used as an index reference for the pods * Holds metadata for each project so that the project name can be used as an index reference * Adds functions 'findNextPods' and 'findPrevPods' allowing clients to request the relevant alternative set of pods from the given namespace * collection.ts * Creates a metadata object for holding the limit and continue reference * Passes the metadata object through to the WsHandler responsible for doing the actual uri fetch * ws-handler.ts * Removes the support for websockets since they require the watch=true uri parameter which is incompatible with limit and continue. * Polling becomes the default mechanism instead for determine if there are any changes * OnMessage receives the response from the cluster and will also update the metadata object with the 'remaining' and 'continue' properties * object-poller.ts * Now responsible for fetching the cluster results, also communicates the metadata as part of the onMessage event back up to the WSHandler

* Current paging algorithm buggy and unnecessarily complex. Using limit, we are trying to save on network data load but this is not the issue with discover tab slowdown. Rather the slowdown is the number of pods being displayed and handled in the UI. * Better methodology: 1) Watch namespace and collect names of pods that are jolokia and add to a set 2) Take a page/chunk of pod names and watch them individually 3) Return only those pods watched for display in the UI 4) Prev/Next will move on the page/chunk in the pod name list and re-init the pod watchers accordingly * Removes the PagingMetadata * Fetches all the pods in a namespace using namespace watcher and adds names to list * Takes chunk from list determined by 'current' page and 'limit' size and starts watching each pod using fieldSelector. Provides only those pods as the collection of pods that k8Service displays for the namespace * Restores the wss handler and connections since no longer using limit and continue references. * No longer need to refresh continue tokens since not used * Changes name of Collection interface to Watched since it also now handles single entities being returned from k8 fieldSelector name API calls * NamespaceClients no longer need to be destroyed and recreated in order to work with pod changes. The pod watchers inside it are renewed if prev/next is called but otherwise those pod watchers already initialised are retained. Only those no longer in the 'page' are removed * Ref key from ClientFactor uses options name rather than continue ref * PagingMetadata interface refactored to Paging and applied to K8 Service and each namespace client

* Places the API Properties in a tab to give all tabs more space * Adds Prev and Next buttons to pods tab to choose the next set of pods to display in the namespace * Puts projects inside an Accordian to separate out the pods logically * KubernetesPods -> KubernetesProjectPods * KubernetesClient removed as folded into Kubernetes component

* Allows the namespace limit of the kubernetes service to be updated and resets all namespace clients to reconnect with the new limit value * Adds number input component to Kubernetes test app

…tio#496) * In order to paginate results, kubernetes uses 'limit' to limit the request and then returns a reference as a 'continue' property. By including the latter in the next query then next set of results can be obtained (see https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#list-pod-v1-core) * globals.ts * Modifies KubeObjectList to support the optional properties of limit and continue defined in the KLimitMetadata type * Adds a PagingMetadata class for keeping track of paging references and the current index of the query, ie. <prev-ref> <index> <next-ref> * PagingMetadata support incremting and decrementing the current index in order to enable the moving to a previous or next set of results. * Kubernetes-service.ts * Refactored to support adding metadata limit to the watching of pods * Synchronises the pod watching code for both Namespace and Cluster config into a single function (initNamespaceClient). * Adds the namespace limit (nsLimit) to the pod options to be attached to the uri * If there is a continue reference for the current project/namespace then it too is added to the options for appending to the path uri * Watching the pods returns a result metadata as well as the pods which contains the podsRemaining property and a continue reference * The podRemaining property must be added to the 'current' paging metadata whilst the continueRef must be added to the 'next' paging metadata * Holds pods by project rather than just pods so that the project name can be used as an index reference for the pods * Holds metadata for each project so that the project name can be used as an index reference * Adds functions 'findNextPods' and 'findPrevPods' allowing clients to request the relevant alternative set of pods from the given namespace * collection.ts * Creates a metadata object for holding the limit and continue reference * Passes the metadata object through to the WsHandler responsible for doing the actual uri fetch * ws-handler.ts * Removes the support for websockets since they require the watch=true uri parameter which is incompatible with limit and continue. * Polling becomes the default mechanism instead for determine if there are any changes * OnMessage receives the response from the cluster and will also update the metadata object with the 'remaining' and 'continue' properties * object-poller.ts * Now responsible for fetching the cluster results, also communicates the metadata as part of the onMessage event back up to the WSHandler

* Current paging algorithm buggy and unnecessarily complex. Using limit, we are trying to save on network data load but this is not the issue with discover tab slowdown. Rather the slowdown is the number of pods being displayed and handled in the UI. * Better methodology: 1) Watch namespace and collect names of pods that are jolokia and add to a set 2) Take a page/chunk of pod names and watch them individually 3) Return only those pods watched for display in the UI 4) Prev/Next will move on the page/chunk in the pod name list and re-init the pod watchers accordingly * Removes the PagingMetadata * Fetches all the pods in a namespace using namespace watcher and adds names to list * Takes chunk from list determined by 'current' page and 'limit' size and starts watching each pod using fieldSelector. Provides only those pods as the collection of pods that k8Service displays for the namespace * Restores the wss handler and connections since no longer using limit and continue references. * No longer need to refresh continue tokens since not used * Changes name of Collection interface to Watched since it also now handles single entities being returned from k8 fieldSelector name API calls * NamespaceClients no longer need to be destroyed and recreated in order to work with pod changes. The pod watchers inside it are renewed if prev/next is called but otherwise those pod watchers already initialised are retained. Only those no longer in the 'page' are removed * Ref key from ClientFactor uses options name rather than continue ref * PagingMetadata interface refactored to Paging and applied to K8 Service and each namespace client

* Places the API Properties in a tab to give all tabs more space * Adds Prev and Next buttons to pods tab to choose the next set of pods to display in the namespace * Puts projects inside an Accordian to separate out the pods logically * KubernetesPods -> KubernetesProjectPods * KubernetesClient removed as folded into Kubernetes component

* Allows the namespace limit of the kubernetes service to be updated and resets all namespace clients to reconnect with the new limit value * Adds number input component to Kubernetes test app

* Allows user to extend/reduce the polling interval for updating of the pods

…awtio#496) * Discover.tsx * Move loading-panel into its own component DiscoverLoadingPanel * Puts the pods into tabs based on the projects/namespaces * New DiscoverProjectContent for each project * DiscoverProjectContent * Lists the limited selection of pods from management-service * When next button is clicked, the signal is sent to the management-service to fetch the 'next' selection of pods for the given namespace * DiscoverToolbar * Sorts the tab order since they are the namespaces * Sorts the pods in each namespace tab * Filters applied in line with patternfly guidelines * Filters of same attribute applied as OR * Filters of different attributes applied as AND * Filters are first concatenated together before being applied * HeaderMenuDropDown * Reimplemented with flyout sub-menus for the pods separated by namespace * context * Replacement of groupds / pods with projects * Addition of refreshing flag to indicate when pods are being refreshed awaiting a management update from prev/next buttons * discover-service split with new discover-project class that encapsulates the discover-projects and pods received from management

* Allows users to change the number of pods displayed in each Discover tab and the polling interval to determine heartbeat to jolokia container ports

…o#496) * The prev/next buttons were created when it was unknown how many pods would be returned for each namespace. Since we now have this information a patternfly pagination component can be implemented instead, complete with pod total, first and last functions. * namespace-client.ts * Returns total number of pods in namespace as separate parameter in callback * Adds first / last / page functions to accompany next and previous * management-service.ts * Adds Paging interface functions as pass-throughs to k8 service * Discover.ts * Adds total pods to tab titles * DiscoverProjectContent.ts * Replaces buttons with pagination component

* namespace-client.ts * Change name of 2nd callback parameter to fullPodCount to make it clear this is the total jolokia pods after filtering but before page slicing * Adds filtering and sorting getters/setters to affect the pods returned by the pod watchers * If any change occurs from filtering or sorting then the callback should be called in order to notify the UI * filter.ts * Refactors the TypeFilter to be a single class containing both namespace and pod name values * kubernetes-service.ts * Add/remove the pod projects to/from the service depending on if there are pods returned after filtering * management-service.ts * Add/remove the mgmt pod projects to/from the service depending on if there are pods returned after filtering * Discover context * Use only 1 filter rather than an array * Breaks out the empty state into its own component for use in other parts of the Discover page * DiscoverProjectContent.ts * Needs refresh Effect to reset the pagination index if it is greater than the project count returned * DiscoverToolbar.ts * When the buttons are clicked call the management service functions for filtering and sorting so that all pod projects down to the k8 service are effected. * discover-service.ts * Only responsible for grouping pods rather as filtering is re-assigned to other services