neutron-lib: Redefine API validator

Bug #1697715 reported by Hirofumi Ichihara on 2017-06-13
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Hirofumi Ichihara

Bug Description

The neutron-lib has API validator. I discussed proper behavior of API validator when I proposed dividing validators into base and specific validator[1].

Problem Description

The validator of neutron-lib was just a package so we had to mix extension specific validator(e.g. validate_dns_name) with generic validators(e.g. validate_string and validate_boolean). Most validator cosumers don't need to import extension specific validator. Therefore, I proposed dividing validators patch[1]. However, the implementation is a little odd because all generic validators are in although it's clearer that the validators package should be named another name(e.g., And also the still includes extension specific validators(e.g. validate_subports). We should divide such validator into another package.

In addition, there are some cases that the validator of neutron-lib is used directly[2, 3, 4] not as API validator. We should not use them directly. If we adopt API versioning, some validator change means the API version bump. It's better to prepare utility function for such use case.

So we have three points.

* Generic validator's place doesn't suit
* Some extension specific validators is still in
* API validator is used directly.


I'm not sure it's RFE but put the tag.

Changed in neutron:
assignee: nobody → Hirofumi Ichihara (ichihara-hirofumi)
tags: added: rfe
Changed in neutron:
status: New → Triaged
Boden R (boden) wrote :

Regarding the 3 points in this RFE:

(1) Generic validator's place doesn't suit I don't see this as a big deal, but if warranted I'd think we could just propose a move via patch.
(2) Some extension specific validators is still in Same as above.
(3) API validator is used directly... I'm not following why this is such a problem. If we decided to version the API at some point, addition changes will likely be needed including updates to the api-defs in neutron-lib. I'd think we could address such issues at that point. In addition the current validator API provides the get_validator() method thereby directly exposing the validator functions to consumers.... Is API versioning coming down the pipeline (maybe I missed it) that's prompting this concern?

this sounds like internal refactoring. We can drop the RFE

Changed in neutron:
importance: Undecided → Wishlist
tags: removed: rfe
summary: - [RFE] neutron-lib: Redefine API validator
+ neutron-lib: Redefine API validator
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers