[Proposal] Service Plugin - for marketplace / other services

OpenPAI Service Plugin

Why we need this

As is known, now OpenPAI has a web-portal plugin mechanism, which let developers easily design independent web-portal functions. This is quite good solution proven in practice, however, it limits developers in the pure front-end area.

However, the frontend plugin seems overwhelmed to develop a service such as

• Mrketplace. Jobs could be published to certain groups of users.
• Gpu Utilization Monitor. It would monitor jobs and do actions to those with low gpu utilization according to pre-defined rules
• Super Scheduler. Jobs could be scheduled among multiple clusters.

These services share some common characteristics, like

• somehow decoupled with OpenPAI core functions
  • involves its own backend and RESTful APIs
  • could serve more than one clusters
• but still be part of OpenPAI ecosystem
  • leverages a cluster's frontend (esp. web-portal) as entry point (the UI is based on webportal plugin)
  • most likely hosted by a cluster (or its K8S), and depends its service discovery
  • most likely depends on its user management

Service Plugin Mechanism

The goal of service plugin mechanism is to reuse functions (commonly shared by most of plugins) and let developers could focus on their own service logic.

Register a plugin

To enable a service plugin, we need to write the basic information to cluster config such as

• <srv.name> - service name
• <srv.endpoint> - service RESTful API end point
• <srv.secret> - a secret service provided for signing tokens

Authentication

The service plugin is assumed to be light-weighted, and it may depends on the user / group management of OpenPAI. The service will trust OpenPAI clusters and let them issuing tokens to their valid users with the registered service secret (<srv.secret>). The payload of issued tokens includes

{
  "cluster": "<cluster-unique-name>",
  "username": "<username>",
  "admin": "true/false",
  "groups": ["<groups>"]
}

When received user's requests with such token, the service could verify it with its stored secret, and get the basic information of user.

Authorization

The service may automatically connect OpenPAI rest server, e.g., to query the job status. To achieve this, user could generate an application token and pass it to the service. This could be implemented by the service UI (webportal plugin) with user's confirmation.

Extension of OpenPAI API

Some APIs could be shared with most service plugins, mainly related to service discovery and user authentication / authorization. Here is a summary of the APIs added, where the OpenPAI API and Service API (common) could be reused (in cluster rest server and JS SDK respectively), and developers could focus in the service API (specific).

OpenPAI API	response
/service-plugin	list of service names
/service-plugin/:service	the registered information of this service, e.g., the endpoint
/service-plugin/:service/token	service authentication token signed with <srv.secret>

Cross Origin Resource Sharing (CORS)

Some services would be connected by multiple clusters, e.g., the Marketplace service may be shared by users from more than one clusters. For host cluster (where the service is hosted), the webportal plugin is OK to access the service backend directly because they in the same origin, however, the UIs in the other clusters will be limited to access service because of CORS.

To solve this issue, the service backend need to enable CORS by middleware such as cors (cors middleware for express).

No implementation file or test is named; begin by locating the existing web-portal plugin mechanism and cluster REST server, then compare their extension points with the proposed service-plugin APIs. Done would require an agreed design covering registration, token issuance, shared APIs, and cross-origin access.