)]}'
{"neutron_lib/api/validators/__init__.py":[{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"832a3f928f43549ab270a3a0dcec12fe14c0e11e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"df140735_7f82ac51","updated":"2017-05-29 16:31:38.000000000","message":"Although this does not break the existing validator consumers, I wonder most logics here can be moved to api.validators.generic from the observations below.\n\n- The public interfaces which neutron-lib consumers really need to consume are add_validator() and get_validator().\n- The implementations of individual validators do not need to be exposed\n\nSo how about defining only add/get_validator() in __init__?\n\nNote that if neutron-lib consumers need to implement a new validator based on generic validators, they can still import them from api.validators.generic module.","commit_id":"59005a0a7815e9ca6065eb89b92e107402f6c2ba"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"4fcd69aeeb4eea611e7d84c20f4d5a36c5dba8e3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"df140735_3908702a","in_reply_to":"df140735_063fa4d6","updated":"2017-06-01 17:42:24.000000000","message":"So one could argue that \u0027type:subports\u0027 is ext specific and shouldn\u0027t be in here right??\n\n\nAs pointed out consumers use validators directly, and I suppose rightly so since they are public functions.\n\nWith that in mind maybe we should just import and add all validators directly in __init__.py so they are \"registred\" by default?? If consumers want to call validator functions directly they could import the respect validator module if needed or just use get_validator for the respective type.","commit_id":"59005a0a7815e9ca6065eb89b92e107402f6c2ba"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"f4ce9febbc8160dea0c7845de1df904f64cfc3fa","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"df140735_c8db894c","in_reply_to":"df140735_2cf14b96","updated":"2017-06-05 13:58:15.000000000","message":"While I understand your points, personally I don\u0027t see a reason to constrain direct usage (invocation) of the validator functions themselves if there\u0027s benefit to our consumers... If we do think consumers should not be calling them directly, then IMHO we should formally change that by making all the validator functions private and updating consumers to not use them.","commit_id":"59005a0a7815e9ca6065eb89b92e107402f6c2ba"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"568d020398b6d68e5f06fef8ea8a70f76651891f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"df140735_2cf14b96","in_reply_to":"df140735_3908702a","updated":"2017-06-01 18:32:11.000000000","message":"I think the validators are two type of consumers. The one usage is as the field validators as the API definition, and the other is a direct usage of validators (by importing them directly). This makes things tricky.\n\nIMHO the validators registered to api.validators.validators by add_validator() are categorized into the former. They are part of the API definitions. If we adopt API versioning, some validator change means the API version bump.\n\nThe latter sounds a utility function. I am not sure this is an expected usage of validators or not. \n\nIMHO validators are some kind of schema definitions and the validators are not utility functions. I think it is the reason that we place \u0027validators\u0027 module under \u0027api.","commit_id":"59005a0a7815e9ca6065eb89b92e107402f6c2ba"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"3f9434e1b5e0d737a454d8e7a11d9e56a27f3a22","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"df140735_8055dc1f","in_reply_to":"df140735_49a84d1e","updated":"2017-05-31 21:12:00.000000000","message":"IMHO the overall approach/idea is warranted.\n\n\nHowever, I question where we draw the line for what\u0027s generic vs. extension specific. To me, the validators dealing with primitive types such as dicts, values, strs, etc. are generic, but perhaps some of the others existing in this file are not. For example we have validators for subports, nameservers, hostroutes, etc... Seems to me some of these maybe candidates to pull out of this generic __init__.py into something more specific (e.g. neutron_lib.api.validators.trunk, etc.).\n\n\nThoughts?","commit_id":"59005a0a7815e9ca6065eb89b92e107402f6c2ba"},{"author":{"_account_id":5367,"name":"boden","email":"bodenvmw@gmail.com","username":"boden"},"change_message_id":"4f08d39e95cabd9e0d6b26ae1008ba31c48fef4b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"df140735_42dba84e","in_reply_to":"df140735_50db804d","updated":"2017-06-06 18:13:47.000000000","message":"Sure; that works for me.","commit_id":"59005a0a7815e9ca6065eb89b92e107402f6c2ba"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"633744f72c1ff88079eadc63e9d420a598619c48","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"df140735_49a84d1e","in_reply_to":"df140735_5e4a4555","updated":"2017-05-30 04:43:36.000000000","message":"Good point. My only point is to clarify the role of each file, but I think we can cover it in reviews.\n\nThus keeping the current version sounds reasonable.\n\nAnother approach is to use \u0027*\u0027 import by defining __all__ in validators/generic.py, but it seems too much.","commit_id":"59005a0a7815e9ca6065eb89b92e107402f6c2ba"},{"author":{"_account_id":7715,"name":"Hirofumi Ichihara","email":"ichihara.hirofumi@gmail.com","username":"Hirofumi-Ichihara"},"change_message_id":"d2aae5f1acab97b42fa7cd3abac65d100a685637","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"df140735_5e4a4555","in_reply_to":"df140735_7f82ac51","updated":"2017-05-30 01:22:38.000000000","message":"\u003e The public interfaces which neutron-lib consumers really need to consume are add_validator() and get_validator().\n\nThe \"is_attr_set\" is also consumed.\n\n\u003e The implementations of individual validators do not need to be exposed\n\nIdeally, it\u0027s right but there are really many consumers use individual validators[1, 2, 3].\n\n[1]: https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L631\n[2]: https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L84\n[3]: https://github.com/openstack/vmware-nsx/blob/master/vmware_nsx/extensions/networkgw.py#L115\n\nBasically I don\u0027t want to push all validators into this __init__ but I guess that it\u0027s more reasonable for projects(neutron, neutron-lib, neutron-stadium and, other plugins). If there are other solutions, I\u0027d like to know.","commit_id":"59005a0a7815e9ca6065eb89b92e107402f6c2ba"},{"author":{"_account_id":7715,"name":"Hirofumi Ichihara","email":"ichihara.hirofumi@gmail.com","username":"Hirofumi-Ichihara"},"change_message_id":"547b032fa003e66f2c6378ce3ad6116ddd0855ed","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"df140735_063fa4d6","in_reply_to":"df140735_8055dc1f","updated":"2017-05-31 23:42:39.000000000","message":"Good point. It\u0027s tough issue. For example, if we put \"type:hostroutes\" out of __init__, I\u0027m not sure how do we define the file name because the validator is used by subnet and router. If we adopt Miguel\u0027s idea, we will be trouble when a extension specific validator will be used by other new extension although now the extension is used by an extension only. Well, it\u0027s corner case.\n\nSo it may be more reasonable that all the validators are in validators.py as before. Or Miguel\u0027s idea.","commit_id":"59005a0a7815e9ca6065eb89b92e107402f6c2ba"},{"author":{"_account_id":7715,"name":"Hirofumi Ichihara","email":"ichihara.hirofumi@gmail.com","username":"Hirofumi-Ichihara"},"change_message_id":"4ab0473e86518bc29ec109f9068119b6283c8fff","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"df140735_50db804d","in_reply_to":"df140735_c8db894c","updated":"2017-06-06 13:18:18.000000000","message":"Hmm, actually validate_subports is used as both types[1, 2]. I think that Akihiro\u0027s idea is ideal although it may be verbose that we prepare duplicated method for direct usage[2]. It\u0027s right from point of API versioning as he commented. I\u0027ll try to propose the idea in Launchpad. It can be discussed on the proposal including candidates should be pulled out of __init__.py so we can merge this patch now?\n\n[1]: https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/trunk.py#L75\n[2]: https://github.com/openstack/neutron/blob/master/neutron/services/trunk/rules.py#L164","commit_id":"59005a0a7815e9ca6065eb89b92e107402f6c2ba"}]}