NovaApiValidationFramework

Nova API Validation Framework

Discussion
https://etherpad.openstack.org/NovaApiValidationFramework

Introduction
Nova is a RESTful API based HTTP service.

These APIs allow for cloud managed server operations.

For example, we can create a virtual machine instance by sending the following POST request to Nova's URI: /servers.

{   "server" : { "name" : "new-server-test", "imageRef" : "http://servers.api.openstack.org/1234/images/52415800-8b69-11e0-9b19-734f6f006e54", "flavorRef" : 1 } } Nova contains many RESTful APIs to facilitate its many features.

Moreover, each RESTful API can be controlled flexibly through multiple parameters.

For example, the above "create a virtual machine instance" API has 19 parameters including "name", "imageRef", etc.

The HTTP service need to validate practically every API parameter in terms of acceptable type and minimum/maximum length and range.

Unnecessary workload can be avoided by validating API parameters before executing the API operation.

Moreover, API validation is an important feature from the viewpoint of HTTP service security.

As Nova is an HTTP service, it should be able to validate API parameters as follows: (ex) ".. is too short.", ".. is too long.", ".. is not integer."
 * Validate every API parameter.
 * Return an error response before API operation, if API parameter is invalid.
 * Unify the error message format of the response, if the cause is the same.

What is necessary for Nova-v3-API
This framework target is Nova-v3-API, because it is new and the API compatibility issues would not happen.

On Havana release, Nova-v3-API is experimental and the API will become generic in Icehouse.

In Icehouse development cycle, the web framework of Nova-v3-API would move to Pecan/WSME.

WSME has original API validation mechanism already, and we'd better to find good API validation feature if we need it.

To find good feature, we'd better to discuss it based on current Nova-v3-API implementation.

This investigation is based on the following commit of Nova source code: commit 5f0591252dc5d6e3f49682f85dcdbd99f692c07a Merge: 0211752 a19d72b Author: Jenkins  Date:  Mon Oct 7 03:14:43 2013 +0000 Merge "Fixes rescue doesn't honor enable password conf for v3"

Basic validation feature
The table of Appendix: Nova-v3-API parameters shows all parameters of Nova-v3-API.

It seems that we need some basic validation features such as:
 * Type validation
 * str(name, ..), int(vcpus, ..), float(rxtx_factor), dict(metadata, ..), list(networks, ..), bool(conbine, ..), None(availability_zone)
 * String length validation
 * 1 - 255
 * Value range validation
 * value >= 0(rotation, ..), value > 0(vcpus, ..), value >= 1(os-multiple-create:min_count, os-multiple-create:max_count)
 * Data format validation
 * Pattern: uuid(volume_id, ..), boolean(on_shared_storage, ..), base64encoded(contents), ipv4(access_ip_v4, fixed_ip), ipv6(access_ip_v6)
 * Allowed list: 'active' or 'error'(state), 'parent' or 'child'(cells.type), 'MANUAL' or 'AUTO'(os-disk-config:disk_config), ...
 * Allowed string: not contain '!' and '.'(cells.name), contain [a-zA-Z0-9_.- ] only(flavor.name, flavor.id)
 * Mandatory validation
 * Required: server.name, flavor.name, ..
 * Optional: flavor.ephemeral, flavor.swap, ..

Auxiliary validation feature
Some parameters have dependency between other parameter.

For example, name or/and availability_zone should be specified when updating an aggregate.

The parameter dependencies are few cases, and the dependency validation feature would not be mandatory.

The cases are the following:
 * Required if not specifying other: (update aggregate: name or availability_zone), (host: status or maintenance_mode), (server: os-block-device-mapping:block_device_mapping or image_ref)
 * Should not specify both: (interface_attachment: net_id and port_id), (server: fixed_ip and port)

Implementation
In Icehouse summit, we have gotten a consensus API validation of v3 API will be implemented with JSONSchema. The implementation is going on https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/v3-api-schema,n,z

Appendix: Nova-v3-API parameters
This investigation is based on the following commit of Nova source code: commit 5f0591252dc5d6e3f49682f85dcdbd99f692c07a Merge: 0211752 a19d72b Author: Jenkins  Date:  Mon Oct 7 03:14:43 2013 +0000 Merge "Fixes rescue doesn't honor enable password conf for v3"

The source files of Nova-v3-API are put under ./nova/api/openstack/compute/plugins/v3/, and there are 79 API methods.

In these APIs, 49 APIs use API parameters of a request body, and they have 148 API parameters.

(32% API parameters(48/148) are not validated with any ways.) The following table shows all API parameters and each API validating implementation.


 * NV : any elements are not validated

Appendix: URL

 * Discussion
 * https://etherpad.openstack.org/NovaApiValidationFramework
 * http://lists.openstack.org/pipermail/openstack-dev/2013-October/016649.html
 * API validation coverage improvement
 * https://etherpad.openstack.org/p/NovaApiValidationCoverage