On Mon, Oct 21, 2013 at 7:14 AM, Kenichi Oomichi <[email protected]>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:[email protected]] > > 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 > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
