Jump to: navigation, search



Provide a general Nova management API for cloud administration applications. The API would include features also provided by nova-manage CLIs. Currently OpenStack administration requires access to command lines for performing management operations. This hinders application developers' ability to create OpenStack applications.

The management API proposal will augment the proposed admin account actions interface (admin account action).

Release Note

See API descriptions for additional details.


The lack of management API, administration is only performed with command lines (CLIs). This hinders application developers' ability to improve the user experience in managing the OpenStack.

There are some administrative APIs within Nova today. However, these features are incomplete, not fully architected, and available only as extensions today. While our initial approach would also be to leverage extensions, the goal for the Management API is to better organize and architect all management features.

User stories

  • As a Cloud Administrator, I want to be able to use my own custom management toolset to standup a Controller, Compute, Network and Images.
  • As a Network integrator, I want to support adding, modifying, or deleting network ranges.
  • As a Cloud Security Administrator, I want to configure users, projects, tenants, roles, quotas from a UI.




This feature provides REST APIs initially as Nova extensions. The API feature set includes POST, PUT, GET, and DELETE operations where applicable.

Management Endpoint

Support a RESTful API, consistent with other OpenStack APIs, at a new endpoint specific to management operations.

Architected API

Rather than creating management APIs unique (unarchitected) for each OpenStack project, this proposal defines an API pattern general to all OpenStack projects.

Plug-ins and Extensions

Future management operations would be easily added as plug-ins based on the pattern described here.


The following examples show how one can manage OpenStack components with the nova-manage CLI. We propose supporting all this functionality via the Management API.

nova-manage CLI proposed management API proposed related API features
nova-manage network list GET .../Manage/Network?name=network_type&Project=name&IPrange=int&Subnet=int List all Networks with matching criteria
nova-manage service list GET ...URI... PUT, ...
nova-manage future options GET ...URI... PUT, ...

For reference, here are several nova-manage CLI capabilities that should also be available via API.

  • Instance Type Management
    • Define or delete a new instance type
  • User/Role Management
    • user
      • add/remove/update/list
  • project
    • add/remove/update/list
  • role
    • add/remove/update/list
  • Service Management
    • service state
    • service list
    • service describe
    • service disable
  • Network management
    • network add/modify/delete/list
  • Flavor management
    • Flavor enable/disable


Implementation of Management APIs as Nova extensions would be based on the OpenStack defined API extension spec.

Sample extension API for "Network" is as below:

Verb URI
GET /Manage/Network?name=network_type&Project=name&IPrange=int&Subnet=int
GET /Manage/Network/detail?name=network_type&Project=name&IPrange=int&Subnet=int
GET /Manage/Network/IPRange
DELETE /Manage/Network/id
POST /Manage/Network
PUT /Manage/Network/id

Sample extension API for "Services" is as below:

Verb URI
GET /Manage/Service/detail?name=service_name&Project=name&Hostname=Host
PUT /Manage/Service/service_name?option=Disable
PUT /Manage/Service/service_name?option=Enable

Other options should follow the same pattern.

Test/Demo Plan

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarizing what was discussed and note any options that were rejected.