)]}'
{"doc/source/faq.rst":[{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"c0d1345405911ae3c61d9e1363d719e2d4a3e3d9","unresolved":false,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Configuration options are a way for deployers to change the behavior"},{"line_number":36,"context_line":"of OpenStack. Applications are not supposed to be aware of the"},{"line_number":37,"context_line":"configuration options defined and used within libraries, because the"},{"line_number":38,"context_line":"library API is supposed to work transparently no matter which backend"},{"line_number":39,"context_line":"is configured."},{"line_number":40,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba3cc151_150cc2eb","line":37,"updated":"2015-07-01 21:58:13.000000000","message":"I think generally this is true for the application code (i\u0027m sure there are valid use-cases out there that contradict this), but I don\u0027t think it is true for the tests.\n\nIt\u0027s nice to be able to look at the tests and know what configuration value I\u0027m modifying without having to mentally map a set_default arg to a configuration option.","commit_id":"b89f5810d757ca2acb2f35e99b7432ff9ce49c1c"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"aa80841230ce662d2e234b0f7ec3be2a0966a33d","unresolved":false,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Configuration options are a way for deployers to change the behavior"},{"line_number":36,"context_line":"of OpenStack. Applications are not supposed to be aware of the"},{"line_number":37,"context_line":"configuration options defined and used within libraries, because the"},{"line_number":38,"context_line":"library API is supposed to work transparently no matter which backend"},{"line_number":39,"context_line":"is configured."},{"line_number":40,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba3cc151_3603a50f","line":37,"in_reply_to":"ba3cc151_150cc2eb","updated":"2015-07-04 20:33:55.000000000","message":"The goal for configuration options is to make them transparent to the application code. If the application has tests that depend on the library being configured a particular way, we should provide fixtures in the library to set up that configuration so the API guarantee can be enforced in the unit tests of the library. Doing it any other way means changes in the library will break the application, or its tests.","commit_id":"b89f5810d757ca2acb2f35e99b7432ff9ce49c1c"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"c0d1345405911ae3c61d9e1363d719e2d4a3e3d9","unresolved":false,"context_lines":[{"line_number":41,"context_line":"Configuration options in libraries can be renamed, moved, and"},{"line_number":42,"context_line":"deprecated just like configuration options in applications. However,"},{"line_number":43,"context_line":"if applications are allowed to read or write the configuration options"},{"line_number":44,"context_line":"directly, treating them as an API, the option cannot be renamed"},{"line_number":45,"context_line":"without breaking the application. Instead, libraries should provide a"},{"line_number":46,"context_line":"programmatic API (usually a :func:`set_defaults` function) for setting"},{"line_number":47,"context_line":"the defaults for configuration options. For example, this function"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba3cc151_d243d011","line":44,"updated":"2015-07-01 21:58:13.000000000","message":"You can\u0027t really rename it without first deprecating it.","commit_id":"b89f5810d757ca2acb2f35e99b7432ff9ce49c1c"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"aa80841230ce662d2e234b0f7ec3be2a0966a33d","unresolved":false,"context_lines":[{"line_number":41,"context_line":"Configuration options in libraries can be renamed, moved, and"},{"line_number":42,"context_line":"deprecated just like configuration options in applications. However,"},{"line_number":43,"context_line":"if applications are allowed to read or write the configuration options"},{"line_number":44,"context_line":"directly, treating them as an API, the option cannot be renamed"},{"line_number":45,"context_line":"without breaking the application. Instead, libraries should provide a"},{"line_number":46,"context_line":"programmatic API (usually a :func:`set_defaults` function) for setting"},{"line_number":47,"context_line":"the defaults for configuration options. For example, this function"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba3cc151_f60c5d3d","line":44,"in_reply_to":"ba3cc151_d243d011","updated":"2015-07-04 20:33:55.000000000","message":"Yes, we can. The configuration library supports reading a value under the old name and making it accessible under the new name. The old name is deprecated, but still works in the configuration file. It does not work in the code accessing the option.","commit_id":"b89f5810d757ca2acb2f35e99b7432ff9ce49c1c"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"c0d1345405911ae3c61d9e1363d719e2d4a3e3d9","unresolved":false,"context_lines":[{"line_number":43,"context_line":"if applications are allowed to read or write the configuration options"},{"line_number":44,"context_line":"directly, treating them as an API, the option cannot be renamed"},{"line_number":45,"context_line":"without breaking the application. Instead, libraries should provide a"},{"line_number":46,"context_line":"programmatic API (usually a :func:`set_defaults` function) for setting"},{"line_number":47,"context_line":"the defaults for configuration options. For example, this function"},{"line_number":48,"context_line":"from ``oslo.log`` lets the caller change the format string and default"},{"line_number":49,"context_line":"logging levels:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba3cc151_95c9b25b","line":46,"updated":"2015-07-01 21:58:13.000000000","message":"Again I think this is strange for unit tests. For applications that want different default values I think it\u0027s fine for them to call set_defaults() since that makes sense. They are changing the default values. For a unit tests this actually isn\u0027t the case and semantically offends my senses.","commit_id":"b89f5810d757ca2acb2f35e99b7432ff9ce49c1c"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"c0d1345405911ae3c61d9e1363d719e2d4a3e3d9","unresolved":false,"context_lines":[{"line_number":50,"context_line":""},{"line_number":51,"context_line":"::"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"    def set_defaults(logging_context_format_string\u003dNone,"},{"line_number":54,"context_line":"                     default_log_levels\u003dNone):"},{"line_number":55,"context_line":"        \"\"\"Set default values for the configuration options used by oslo.log.\"\"\""},{"line_number":56,"context_line":"        # Just in case the caller is not setting the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba3cc151_354c66c7","line":53,"updated":"2015-07-01 21:58:13.000000000","message":"You probably want to call out the fact that set_defaults needs to register the library\u0027s options.","commit_id":"b89f5810d757ca2acb2f35e99b7432ff9ce49c1c"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"aa80841230ce662d2e234b0f7ec3be2a0966a33d","unresolved":false,"context_lines":[{"line_number":50,"context_line":""},{"line_number":51,"context_line":"::"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"    def set_defaults(logging_context_format_string\u003dNone,"},{"line_number":54,"context_line":"                     default_log_levels\u003dNone):"},{"line_number":55,"context_line":"        \"\"\"Set default values for the configuration options used by oslo.log.\"\"\""},{"line_number":56,"context_line":"        # Just in case the caller is not setting the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba3cc151_9612b157","line":53,"in_reply_to":"ba3cc151_354c66c7","updated":"2015-07-04 20:33:55.000000000","message":"The way this version is implemented, it doesn\u0027t, because the option definition itself is being modified. This isn\u0027t a good example, so thanks for pointing that out. I\u0027ll update it.","commit_id":"b89f5810d757ca2acb2f35e99b7432ff9ce49c1c"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"c0d1345405911ae3c61d9e1363d719e2d4a3e3d9","unresolved":false,"context_lines":[{"line_number":95,"context_line":"is subject to change. ``oslo.config`` makes it easy to communicate"},{"line_number":96,"context_line":"that change to a deployer in a way that allows their old configuration"},{"line_number":97,"context_line":"files to continue to work. It has no mechanism for doing that in"},{"line_number":98,"context_line":"application code, however."}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba3cc151_1567e24d","line":98,"updated":"2015-07-01 21:58:13.000000000","message":"Wouldn\u0027t it be pretty trivial to  provide a deprecation warning if an deprecated option is being set from code?","commit_id":"b89f5810d757ca2acb2f35e99b7432ff9ce49c1c"}]}