neutron-lib: Redefine API validator

[Hirofumi Ichihara]

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 __init__.py although it's clearer that the validators package should be named another name(e.g. base.py, generic.py). And also the __init__.py 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 __init__.py.
* Some extension specific validators is still in __init__.py.
* API validator is used directly.

[1]: https://review.openstack.org/#/c/467236/
[2]: https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L631
[3]: https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L84
[4]: https://github.com/openstack/vmware-nsx/blob/master/vmware_nsx/extensions/networkgw.py#L115

[Hirofumi Ichihara (ichihara-hirofumi)]

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

[Boden R (boden)]

Regarding the 3 points in this RFE:

(1) Generic validator's place doesn't suit __init__.py... 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 __init__.py... 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?

[Armando Migliaccio (armando-migliaccio)]

this sounds like internal refactoring. We can drop the RFE