Difference between revisions of "ManagementAPI"
Line 58: | Line 58: | ||
| proposed management API | | proposed management API | ||
| proposed related API features | | proposed related API features | ||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
| nova-manage network list | | nova-manage network list | ||
| GET .../Manage/Network?''name''=network_type&''Project''=name&''IPrange''=int&''Subnet''=int | | GET .../Manage/Network?''name''=network_type&''Project''=name&''IPrange''=int&''Subnet''=int | ||
| List all Networks with matching criteria | | List all Networks with matching criteria | ||
+ | |- | ||
+ | | nova-manage service list | ||
+ | | GET ...URI... | ||
+ | | PUT, ... | ||
|} | |} | ||
Line 124: | Line 124: | ||
|- | |- | ||
| GET | | GET | ||
− | | /Manage/Service/detail?''name''= | + | | /Manage/Service/detail?''name''=service_name&''Project''=name&''Hostname''=Host |
|- | |- | ||
| PUT | | PUT |
Revision as of 21:12, 9 April 2012
- Launchpad Entry: Management API
- Created: 02 April 2012
- Contributors: Yehia Beyh, Lyle Wilkinson, Divakar Nandavar
<<TableOfContents()>>
Summary
Provide a general 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.
Rationale
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 Nova security Administrator, I want to configure users, projects, tenants, roles, quotas from a UI.
Assumptions
TBD
Design
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.
Examples
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.
TODO: convert list below to table ...
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, ... |
- 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
Implementation
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?name=network_type&Project=name&IPrange=int&Subnet=int |
GET | /Manage/Service/detail?name=service_name&Project=name&Hostname=Host |
PUT | /Manage/Service/Disable |
PUT | /Manage/Service/Enable |
TODO: Similar other extensions to be designed.
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.
----