)]}'
{"specs/juno/config-validator-simple.rst":[{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"5610e49d78028be93b1ea899d5e2b96f117c88ff","unresolved":false,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"At a cursory level this would behave like the oslo-incubator config.generator:"},{"line_number":47,"context_line":"modules would be loaded (registering config options), the validator would then"},{"line_number":48,"context_line":"scan the config file and perform checks."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Based on the information available with the current config registration system,"},{"line_number":51,"context_line":"there are a few checks that the validator could perform:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_ced76422","line":48,"updated":"2014-05-21 22:22:01.000000000","message":"Can you be more specific about how \"modules would be loaded\" would work? Do you mean using entry points, or by scanning the filesystem for modules? Using some sort of entry-points system seems safer.","commit_id":"a511fd702f8a70d3bb6ab5c4dee201c62dba3f42"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"0b481d4d97bdde2123fe07d52615867fea00c4f3","unresolved":false,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"At a cursory level this would behave like the oslo-incubator config.generator:"},{"line_number":47,"context_line":"modules would be loaded (registering config options), the validator would then"},{"line_number":48,"context_line":"scan the config file and perform checks."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Based on the information available with the current config registration system,"},{"line_number":51,"context_line":"there are a few checks that the validator could perform:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_6d84e55d","line":48,"in_reply_to":"1ae5cdf2_d3a593a2","updated":"2014-06-13 15:03:11.000000000","message":"That scanning code is extremely naive and uses patterns we\u0027re trying to move away from (registering options when modules are imported, for example). The newer apps have had some special issues with the generator, too. For example, in Heat they use the same option definitions in multiple groups that end up being defined at runtime. That isn\u0027t easy to represent in the code for the generator to discover them, so they use the \"libraries\" argument to the generator, which loads entry points that return the list of options and groups.","commit_id":"a511fd702f8a70d3bb6ab5c4dee201c62dba3f42"},{"author":{"_account_id":6699,"name":"Scott Devoid","email":"devoid@anl.gov","username":"scott-devoid"},"change_message_id":"4b716d3025fa9ea242d67a5f498980633110f661","unresolved":false,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"At a cursory level this would behave like the oslo-incubator config.generator:"},{"line_number":47,"context_line":"modules would be loaded (registering config options), the validator would then"},{"line_number":48,"context_line":"scan the config file and perform checks."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Based on the information available with the current config registration system,"},{"line_number":51,"context_line":"there are a few checks that the validator could perform:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_d3a593a2","line":48,"in_reply_to":"7adec928_ced76422","updated":"2014-06-05 21:45:52.000000000","message":"I don\u0027t know how entry-points work. The generator code accepts a list of modules as arguments, so that was how I planned to implement it initially.","commit_id":"a511fd702f8a70d3bb6ab5c4dee201c62dba3f42"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"5610e49d78028be93b1ea899d5e2b96f117c88ff","unresolved":false,"context_lines":[{"line_number":56,"context_line":"- Raise a warning if an option is depreciated."},{"line_number":57,"context_line":"- Raise a warning if an option in the file (section, key, value),"},{"line_number":58,"context_line":"  is set to the default value. Note that this kind of behavior would"},{"line_number":59,"context_line":"  be configurable in the library."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"This level of validation is achievable with no changes to the config"},{"line_number":62,"context_line":"registration syntax. And it would catch many deployer mistakes that now"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_2ee60817","line":59,"updated":"2014-05-21 22:22:01.000000000","message":"We have several places where one option setting makes a group of others irrelevant (i.e., when a particular driver is enabled the settings for other drivers can be ignored). How will you handle that?","commit_id":"a511fd702f8a70d3bb6ab5c4dee201c62dba3f42"},{"author":{"_account_id":6699,"name":"Scott Devoid","email":"devoid@anl.gov","username":"scott-devoid"},"change_message_id":"4b716d3025fa9ea242d67a5f498980633110f661","unresolved":false,"context_lines":[{"line_number":56,"context_line":"- Raise a warning if an option is depreciated."},{"line_number":57,"context_line":"- Raise a warning if an option in the file (section, key, value),"},{"line_number":58,"context_line":"  is set to the default value. Note that this kind of behavior would"},{"line_number":59,"context_line":"  be configurable in the library."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"This level of validation is achievable with no changes to the config"},{"line_number":62,"context_line":"registration syntax. And it would catch many deployer mistakes that now"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_33c23753","line":59,"in_reply_to":"7adec928_2ee60817","updated":"2014-06-05 21:45:52.000000000","message":"See the next two paragraphs. I see this as a next-step since it touches a lot of things.","commit_id":"a511fd702f8a70d3bb6ab5c4dee201c62dba3f42"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"0b481d4d97bdde2123fe07d52615867fea00c4f3","unresolved":false,"context_lines":[{"line_number":68,"context_line":"before any of it\u0027s config options take effect. So if the options"},{"line_number":69,"context_line":"are set but the driver is not loaded, a warning should be produced."},{"line_number":70,"context_line":"To do this, new syntax could be added to config registration declaring"},{"line_number":71,"context_line":"a type of dependency on another config option."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_6deb0513","line":71,"updated":"2014-06-13 15:03:11.000000000","message":"I don\u0027t think we need new syntax, but we can figure that out when the time comes.","commit_id":"a511fd702f8a70d3bb6ab5c4dee201c62dba3f42"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"5610e49d78028be93b1ea899d5e2b96f117c88ff","unresolved":false,"context_lines":[{"line_number":104,"context_line":"Work Items"},{"line_number":105,"context_line":"----------"},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"- Implement basic validator interface with unit tests."},{"line_number":108,"context_line":"- Implement a simple script that calls the validator for a given project."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Hopefully projects using oslo.config will then integrate the library"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_eeb34008","line":107,"updated":"2014-05-21 22:22:01.000000000","message":"Can you provide some details here about what the validator API will look like? How will functions be registered? Executed? How are errors or warnings differentiated? Do errors halt progress, or are all of the validators consulted?","commit_id":"a511fd702f8a70d3bb6ab5c4dee201c62dba3f42"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"5610e49d78028be93b1ea899d5e2b96f117c88ff","unresolved":false,"context_lines":[{"line_number":116,"context_line":""},{"line_number":117,"context_line":"None"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":""},{"line_number":120,"context_line":".. [1] https://blueprints.launchpad.net/oslo/+spec/service-validation"},{"line_number":121,"context_line":""},{"line_number":122,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_4ec0b47c","line":119,"updated":"2014-05-21 22:22:01.000000000","message":"The updated template includes a \"references\" section at the end here. Please add https://etherpad.openstack.org/p/service-validation to the references list when you rebase after https://review.openstack.org/94359 is merged.","commit_id":"a511fd702f8a70d3bb6ab5c4dee201c62dba3f42"}]}