Current implementation of schema validation in glance is not compatible to use "oneOf". This will require substantial changes to incorporate "oneOf" implementation (Please refer patch [1])and that has some cons which are mentioned below:
1. Additional GenericJSONSchema class needs to write in galnce.schema module to support the complex schama for request and response validation which basically overrides the glance.schema.Schema class and validate the request object with the whole schema (without extracting the properties only).
2. For the validation of response at glanceclient side the minimal method in glance.schema.GenericJSONSchema class [1] is used to get the schema from glance in that we are passing whole schema and "properties" parameter as "None", that doesn't make any sense and that will cause problem when other services will call the member api because is_base_property() method in [2] will be call to use the member api in other service.(like cinder is using the glance service where is_base_property() method is used to get the image list)
3. At the glance side glance.api.v2.image_member.get_collection_schema() method [3] is used for the member list api so if we passed the whole schema to the glance.schema.CollectionSchema() class then it will degrades the performance when there will be maximum records, so passed the “image-member-detail-response “ definitions properties from member schema in [1] and this seems hackish.
So to overcome all these cons, the additional maxLength check for member_id (using the strutils.check_string_length() method of oslo_utils) in glance.api.v2.RequestDeserializer.create() method will solve all the problem.
Hi All,
Current implementation of schema validation in glance is not compatible to use "oneOf". This will require substantial changes to incorporate "oneOf" implementation (Please refer patch [1])and that has some cons which are mentioned below:
1. Additional GenericJSONSchema class needs to write in galnce.schema module to support the complex schama for request and response validation which basically overrides the glance. schema. Schema class and validate the request object with the whole schema (without extracting the properties only).
2. For the validation of response at glanceclient side the minimal method in glance. schema. GenericJSONSche ma class [1] is used to get the schema from glance in that we are passing whole schema and "properties" parameter as "None", that doesn't make any sense and that will cause problem when other services will call the member api because is_base_property() method in [2] will be call to use the member api in other service.(like cinder is using the glance service where is_base_property() method is used to get the image list)
3. At the glance side glance. api.v2. image_member. get_collection_ schema( ) method [3] is used for the member list api so if we passed the whole schema to the glance. schema. CollectionSchem a() class then it will degrades the performance when there will be maximum records, so passed the “image- member- detail- response “ definitions properties from member schema in [1] and this seems hackish.
So to overcome all these cons, the additional maxLength check for member_id (using the strutils. check_string_ length( ) method of oslo_utils) in glance. api.v2. RequestDeserial izer.create( ) method will solve all the problem.
[1] https:/ /review. openstack. org/#/c/ 422603/ 1 /github. com/openstack/ python- glanceclient/ blob/master/ glanceclient/ v2/schemas. py#L100 /github. com/openstack/ glance/ blob/master/ glance/ api/v2/ image_members. py#L383
[2] https:/
[3] https:/