The following document describes the v2 api for the scheduler.
Projects API
Projects are new concept that has been introduced in the v2 api. They allow multi-tenancy in the application from a user perspective.
POST
POST URL: /v2/project POST BODY: { name: "Name of Project" //must be unique } RETURN STATUS: 201 RETURN BODY: { name: "name of the project" }
GET, DELETE
GET URL: /v2/project/{project-name} RETURN STATUS: 200 RETURN BODY: { name: "Name of Project" //must be unique } DELETE URL: /v2/project/{project-name} RETURN STATUS: 204
Resource Bundle API
The resource bundle API is now keyed off the Project API
Resource Bundle Names and Versions are unique within a Project.
POST
URL: /v2/project/{project-name}/rb POST BODY: { "rb-name": "test-rbdef", "rb-version": "v1", "description": "testing resource bundle definition api", } RETURN STATUS: 201 RETURN BODY: { "rb-name": "test-rbdef", "rb-version": "v1", "description": "testing resource bundle definition api",}
GET, DELETE
GET URL: /v2/project/{project-name}/rb/{rb-name}/{rb-version} RETURN STATUS: 200 RETURN BODY: { "rb-name": "test-rbdef", "rb-version": "v1", "description": "testing resource bundle definition api" } DELETE URL: /v2/project/{project-name}/rb/{rb-name}/{rb-version} RETURN STATUS: 204
Profile API
The Profile API is now keyed off the new rb API based on projects
Profile names are unique within a resource bundle and version.
Changes with respect to V1 API:
- rb-name, rb-version is removed as it is part of the path
- release-name is removed as profile-name will be used
- kubernetes-version is removed as that is no longer in the scope of the profile
POST
URL: /v2/project/{project-name}/rb/{rb-name}/{rb-version}/profile POST BODY: { "profile-name": "test-rbdef", "namespace": "onap", //Kubernetes namespace to install the charts in "description": "testing resource bundle definition api", } RETURN STATUS: 201 RETURN BODY: { "rb-name": "test-rbdef", "rb-version": "v1", "profile-name": "test-rbdef", "namespace": "v1", "description": "testing resource bundle definition api" }
GET, DELETE
GET URL: /v2/project/{project-name}/rb/{rb-name}/{rb-version}/profile/{profile-name} RETURN STATUS: 200 RETURN BODY: { "rb-name": "test-rbdef", "rb-version": "v1", "profile-name": "test-rbdef", "namespace": "v1", "description": "testing resource bundle definition api" } DELETE URL: /v2/project/{project-name}/rb/{rb-name}/{rb-version}/profile/{profile-name} RETURN STATUS: 204
Intent API
Intent API is different compared to the other APIs documented here.
There is a main Intent API that allows you to create a Parent Intent and any SUB Intents are forwarded to their respective handlers.
POST
URL: /v2/project/{project-name}/rb/{rb-name}/{version}/intent POST BODY: { "intent-name": "test-rbdef", "description": "testing resource bundle definition api" } RETURN STATUS: 201 RETURN BODY: { "intent-name": "test-rbdef", "description": "testing resource bundle definition api" }
GET, DELETE
GET URL: /v2/project/{project-name}/rb/{rb-name}/{version}/intent/{intent-name} RETURN STATUS: 200 RETURN BODY: { "intent-name": "test-rbdef", "description": "testing resource bundle definition api" } DELETE URL: /v2/project/{project-name}/rb/{rb-name}/{version}/intent/{intent-name} RETURN STATUS: 204
Sub Intent API
Sub Intents are handled by Adapters that are installed in k8splugin.
POST
URL: /v2/project/{project-name}/rb/{rb-name}/{version}/intent/{intent-name}/{sub-intent}/...The remaining URL is forwarded to the POST Handler of the Sub Intent AdapterPOST BODY: { // Defined by the sub intent and forwarded to and handled by it } RETURN STATUS: 201 RETURN BODY: { // Defined by the sub intent and handled by it }
router.HandleFunc("/{pr-name}/rb/{rb-name}/{rb-version}/intent/{intent-name}/{sub-intent-name}", adapterMgr.GetAdapter(sub-intent-name).HandlePost).Methods("POST") router.HandleFunc(`/{pr-name}/rb/{rb-name}/{rb-version}/intent/{intent-name}/{sub-intent-name}/{rest:[a-zA-Z0-9=\-\/]+}`, adapterMgr.GetAdapter(sub-intent-name).HandlePost).Methods("POST") //HandlePost will then figure out if it needs the “rest” or just r.body is enough. //json.Unmarshal will happen in the HandlePost preventing any map[string]interface{} casts.
GET, DELETE
GET URL: /v2/project/{project-name}/rb/{rb-name}/{version}/intent/{intent-name}/{sub-intent}/... RETURN STATUS: 200 RETURN BODY: { // Defined by the sub intent and handled by it } DELETE URL: /v2/project/{project-name}/rb/{rb-name}/{version}/intent/{intent-name}/{sub-intent} RETURN STATUS: 204
Instantiation API
Instantiation API is now based on the Profile API instead of having its own URL root.
POST
URL: /v2/project/{project-name}/rb/{rb-name}/{rb-version}/profile/{profile-name}/instance POST BODY: { "cloudRegion": "cloud-region" //name of logical cloud to use for instantiation "intent": "intent-name", //name of intent to use for instantiation //overrideValues overrides values from the helm charts and allows for instantiation time //variable overrides. "overrideValues": { imageRepository: "registry.hub.docker.com" } } RETURN STATUS: 201 RETURN BODY: { "id": "laughing_robinson", "rb-name": "test-rbdef", "rb-version": "v1", "profile-name": "test-rbdef", "cloudRegion": "kud", "namespace": "testinstallns", "resources": [ { "GVK": { "Group": "", "Version": "v1", "Kind": "Service" }, "Name": "mongo" }, { "GVK": { "Group": "", "Version": "v1", "Kind": "Service" }, "Name": "mongo-read" } ] }
GET, DELETE
GET URL: /v2/project/{project-name}/rb/{rb-name}/{rb-version}/profile/{profile-name}/instance/{instance-id} RETURN STATUS: 200 RETURN BODY: { "id": "laughing_robinson", "rb-name": "test-rbdef", "rb-version": "v1", "profile-name": "test-rbdef", "cloudRegion": "kud", "namespace": "testinstallns", "resources": [ { "GVK": { "Group": "", "Version": "v1", "Kind": "Service" }, "Name": "mongo" }, { "GVK": { "Group": "", "Version": "v1", "Kind": "Service" }, "Name": "mongo-read" } ] } DELETE URL: /v2/project/{project-name}/rb/{rb-name}/{rb-version}/profile/{profile-name}/instance/{instance-id} RETURN STATUS: 204