...
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
Draft REST API
This is a first pass at a set of REST APIs that support the following workflows. For actor definitions, see NDS Labs Use Cases.
- Cluster admin can manage the "service library" (collection of definitions of available services, similar to the Charm store)
- Cluster admin can manage "projects" (a project is a namespace and set of storage/computation quotas)
- Project admin can view all available site services and storage resources.
- Project admin can manage deployed services (add/remove), associate services where necessary, and assign volumes to services.
A few definitions:
...
- to
...
- services.
Base path: /api/{version}/
| Path | Action | Project Admin | Cluster Admin | Notes |
|---|---|---|---|---|
| /services | List, add site-wide and project-specific services | GET, PUT | PUT | |
| /services/{service-id} | Get, update, delete site-wide services | GET | PUT, DELETE | |
| /projects | List, add projects | GET, PUT | ||
| /projects/{project-id} | Get, update, delete project | GET, PUT | DELETE | |
| /projects/{project-id}/serviceInstances | List, add project services | GET, PUT | ||
| /projects/{project-id}/serviceInstances/{instance-id} | Get, update, delete project service | GET, PUT, DELETE | ||
| /projects/{project-id}/serviceInstances/{instance-id}/status | Get, update, delete project services status | GET, PUT, DELETE | ||
| /projects/{project-id}/volumes | List, add project volumes | GET, PUT | ||
| /projects/{project-id}/volumes/{volume-id} | Get, update, delete project volumes | GET, PUT, DELETE |
...
The prototype NDSLabs API Server will be used by the CLI and GUI applications.
...
To facilitate rapid development, we'll use the Swagger editor and codegen with Java bindings:
- Use Swagger editor to define API (running on some dev VM)
- Use Swagger codegen to generate JAX-RS server bindings and ? client bindings
- API server will run under Jetty (default)
Components
We envision the following components:
- CLI
- API Server (essentially either a webapp running under JettyJetty application or Go server)
- etcd (configuration storage): Store for service library, project definitions, and services
- Kubernetes API client (for interaction with Kubernetes services, etc).
- Openstack client to handle volume allocation/initialization tasks
...
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
API Authentication
- For the CLI, we could follow the Kubernetes API server authentication model using client certificates. They use openssl/easyrsa to sign client certificates where the common name is the username (or in our case, project namespace).
- This is not useful for the GUI, which might require user authentication. Perhaps we can pre-generate a password?
Service definitions
How will we manage service definitions going forward so that new services can be added without requiring access to the nds-labs repository? We need to handle two cases: official or trusted services and services under development. The Docker model might suit us: official service definitions are stored in an SCM repo. A repo watcher polls HEAD for changes and imports new definitions into the service library (e.g., etcd). We can use pull requests to handle trust and verification. To handle development, we could store "draft" definitions in a way that are only accessible to a specific project. For example, the developer could issue "cli add service -f myservice.spec" and the service would be added to services/{namespace} or namespace/services. The "cli list services" would return both official and project-local definitions.