[8] Refactor UI DeploymentsService for external consumers

[andrewazores]

Parent:

Description

As a developer, I would like to be able to use the WIT Deployments API from other areas of OSIO outside of the Deployments page, without rolling my own service but without having to mold to the design of the existing DeploymentsService.

Notes

The DeploymentsService was originally designed tailored specifically for the Deployments page and the components that live there, and so the service provides functions specifically designed to return data in the shape expected by/easiest to consume for those components, and does some internal replay, caching, and polling logic to allow the components to be as dumb as possible. The service is also not provided at the module level since this would further complicate its internal polling and caching logic by extending the service's lifecycle, so consumers need to provide the service (as well as its two configuration dependencies intended for easier testability) at the component level.

However, there are more and more places elsewhere in OSIO that are gaining dependencies on the data provided by the Deployments WIT backend. So far, these have been using the DeploymentsService to access this API. This is not ideal since not all consumers will have the same data format needs, nor necessarily require the same polling and caching logic.

Tasks

• Provide DeploymentApiService #2924 Provide DeploymentApiService
• Refactor DeploymentsService to use DeploymentApiService #2925 Refactor DeploymentsService to use DeploymentApiService
• Move Deployments interfaces out of deployments.service.ts #2962 Move Deployments interfaces out of deployments.service.ts
• Refactor EnvironmentWidget to use DeploymentApiService #2961 Refactor EnvironmentWidget to use DeploymentApiService

[andrewazores]

The current proposal is to extract the HTTP requests out from the DeploymentsService and move them into a new DeploymentApiService. All of the functions exposed by the DeploymentApiService would reflect one WIT API endpoint and return a plain Angular HTTP request Observable, with no caching or polling. The DeploymentApiService would have no dependencies other than Angular HTTP and would be provided at the Deployments Module level. Any non-Deployments page consumers would then be refactored to consume the DeploymentApiService rather than the DeploymentsService. The DeploymentsService would be refactored as a layer atop the DeploymentApiService to provide polling and caching and massage the data into the shape expected by the Deployments page. If other consumers have their own complex logic to build on top of the raw HTTP requests then they would be recommended to build their own services layered atop the DeploymentApiService, mirroring the approach taken by the Deployments area.

[chrislessard]

This service will be needed for the new "resources" tab of the user's settings page (the associated issue for its implementation can be found here).

As you can see, the service will require info on CPU, Memory, Secret, Persistent Volume Claim, Replication Controller and Service usage. Ideally, it will be possible to make a single request for each of these things, with a refresh occurring on the users behalf whenever they want.

[andrewazores]

Closing as all child tasks have been completed. DeploymentApiService is available and ready for external consumers (and EnvironmentWidget has already become the first), and DeploymentsService has been cleaned up for Deployments-area specific usage.