Open Stack

On Tue, Oct 15, 2013 at 5:44 PM, Kenichi Oomichi
<oomichi at mxs.nes.nec.co.jp>wrote:

>
> Hi,
>
> # I resend this because gmail distinguished my previous mail as spam one..
>
> I'd like to know what validation feature is really needed for Nova v3 API,
> and I hope this mail will be a kick-off of brain-storming for it.
>
> << Introduction >>
> I have submitted a blueprint "nova-api-validation-fw".
> The purpose is comprehensive validation of API input parameters.
> 32% of Nova v3 API parameters are not validated with any ways[1], and the
> fact would cause an internal error if some clients just send an invalid
> request. If an internal error happens, the error message is output to a
> log file and OpenStack operators should research its reason. It would be
> hard work for the operators.
>
>
We have tried to improve this for the V3 API but we still have a way to go.
I believe a validation framework like you have proposed would be very
useful - and cleanup the extension code.


> In Havana development cycle, I proposed the implementation code of the BP
> but it was abandoned. Nova web framework will move to Pecan/WSME, but my
> code depended on WSGI. So the code would have merits in short term, but not
> in long term.
> Now some Pecan/WSME sessions are proposed for Hong-Kong summit, so I feel
> this situation is a good chance for this topic.
>
>
I proposed the Nova Pecan/WSME session for the summit, but I do have a few
reservations about whether the transition will be worth the pain I think
will be involved. So I don't think its by any means clear that Pecan/WSME
will be something we will do in Icehouse and your wsgi based implementation
could be what we want to go ahead with.


> For discussing, I have investigated all validation ways of current Nova v3
> API parameters. There are 79 API methods, and 49 methods use API parameters
> of a request body. Totally, they have 148 API parameters. (details: [1])
>
> Necessary features, what I guess now, are the following:
>
> << Basic Validation Feature >>
> Through this investigation, 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 a 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)
>
>
These all sound useful.


> << API Documentation Feature >>
> WSME has a unique feature which generates API documentations from source
> code.
> The documentations(
> http://docs.openstack.org/developer/ceilometer/webapi/v2.html)
> contains:
> * Method, URL (GET /v2/resources/, etc)
> * Parameters
> * Reterun type
> * Parameter samples of both JSON and XML
>

Do you know if the production of JSON/XML samples and integration of them
into the api documentation
is all autogenerated via wsme?

Regards,

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131016/a35b0963/attachment.html>