Open Stack

Hi Doug,

Thanks again.

-----Original Message-----
From: Doug Hellmann [mailto:doug.hellmann at dreamhost.com] 
Sent: Tuesday, October 22, 2013 6:51 AM
To: Ohmichi, Kenichi
Cc: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Nova] What validation feature is necessary for Nova v3 API
>
> On Mon, Oct 21, 2013 at 7:14 AM, Kenichi Oomichi <oomichi at mxs.nes.nec.co.jp> wrote:
>>
>> 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.

I see. I will start to implement this features for WSME.

BTW, now the launchpad of WSME does not contain "Blueprint" pages.
Is it OK to register this features as a bug?
or will you open the "Blueprint" page?


>>>> * 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.

Nice info, I will implement other type validations by referring the boolean type.


>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.

Thanks, I get motivated by your comment:-)


Thanks
Ken'ichi Ohmichi