Open Stack

On Mon, Oct 21, 2013 at 7:14 AM, Kenichi Oomichi
<oomichi at mxs.nes.nec.co.jp>wrote:

>
> Hi Doug,
>
> Thank you for your advice.
>
> Some validation features seem necessary as basic features for Nova APIs.
> so I am trying to pick necessary features for WSME on the following
> inline messages.
>
> Could you check them?
>
> > -----Original Message-----
> > From: Doug Hellmann [mailto:doug.hellmann at dreamhost.com]
> > Sent: Thursday, October 17, 2013 3:51 AM
> > To: OpenStack Development Mailing List
> > Subject: Re: [openstack-dev] [Nova] What validation feature is necessary
> for Nova v3 API
> >>>
> >>> 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)
>
> Ceilometer has class BoundedInt.
> (
> https://github.com/openstack/ceilometer/blob/master/ceilometer/api/controllers/v2.py#L79
> )
> This class seems useful for the above value range validation.
> Can we implement this feature on WSME?
> Or should we implement this on Oslo?
>

I think it makes sense to add some of these validation features directly to
WSME unless they are OpenStack-specific.


>
> Also we would be able to implement the string length validation with
> the similar code.
>

Yes, I think you're right.


>
>
> >>> * Data format validation
> >>>  * Pattern:
> >>>    uuid(volume_id, ..), boolean(on_shared_storage, ..),
> base64encoded(contents),
> >>>    ipv4(access_ip_v4, fixed_ip), ipv6(access_ip_v6)
>
> This feature also seems implemantable by enhancing the above string
> validation.
>

Yes, I could see having different types for each of those things. I believe
there is already a boolean type.


>
> >>>  * Allowed list:
> >>>    'active' or 'error'(state), 'parent' or 'child'(cells.type),
> >>>    'MANUAL' or 'AUTO'(os-disk-config:disk_config), ...
>
> WSME has this feature(wtypes.Enum) already.
>

Yes


>
> >>>  * Allowed string:
> >>>    not contain '!' and '.'(cells.name),
> >>>    contain [a-zA-Z0-9_.- ] only(flavor.name, flavor.id)
>
> This feature also seems implemantable.
>

Yes


>
> >>> * Mandatory validation
> >>>  * Required: server.name, flavor.name, ..
> >>>  * Optional: flavor.ephemeral, flavor.swap, ..
>
> WSME has this feature(mandatory argument) already.
>

Yes

Thanks for doing this analysis. It looks like with a little bit of work on
WSME, we will have a nice library of reusable validators.

Doug


>
>
> Thanks
> Ken'ichi Ohmichi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131021/96f8ad94/attachment-0001.html>