)]}'
{"specs/kilo/provide-dictionary-backed-configopts.rst":[{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"01280f55164f27308c88442f8ee918302c8afe80","unresolved":false,"context_lines":[{"line_number":3,"context_line":"  see http://sphinx-doc.org/rest.html"},{"line_number":4,"context_line":""},{"line_number":5,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":6,"context_line":" The title of your blueprint"},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"https://blueprints.launchpad.net/oslo.config/+spec/dictionary-backend-config-opts"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_3b96194d","line":6,"updated":"2014-10-22 19:48:35.000000000","message":"needs a title","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"295a1d50603fd721323851e2d598a757336c5eb5","unresolved":false,"context_lines":[{"line_number":3,"context_line":"  see http://sphinx-doc.org/rest.html"},{"line_number":4,"context_line":""},{"line_number":5,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":6,"context_line":" The title of your blueprint"},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"https://blueprints.launchpad.net/oslo.config/+spec/dictionary-backend-config-opts"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_34f46386","line":6,"in_reply_to":"9aa7fdbe_3b96194d","updated":"2014-10-23 02:36:57.000000000","message":"Will do, good catch :)","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"01280f55164f27308c88442f8ee918302c8afe80","unresolved":false,"context_lines":[{"line_number":99,"context_line":"openstack are stuck in a rock-and-a-hard place since now they either"},{"line_number":100,"context_line":"have to avoid using the mentioned libraries or change there API to be"},{"line_number":101,"context_line":"one that only really works in the openstack community where the usage of"},{"line_number":102,"context_line":"``ConfigOpts`` is prevalent."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"Those libraries could in theory completely use the ``URL`` object support for"},{"line_number":105,"context_line":"interacting with oslo libraries if it was fully functional and was a true first"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_3b40d9a4","line":102,"updated":"2014-10-22 19:48:35.000000000","message":"Part of the problem with libraries like oslo.messaging is that the library itself doesn\u0027t know what the options are. They are defined by the driver plugins, and can vary between drivers. So how would something that wanted to use oslo.messaging know what values to put into a dictionary to pass to the DictConfigOpts constructor when setting up an instance?","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"0f092b14ea5a93be7198d6b7dd9249d88967495c","unresolved":false,"context_lines":[{"line_number":99,"context_line":"openstack are stuck in a rock-and-a-hard place since now they either"},{"line_number":100,"context_line":"have to avoid using the mentioned libraries or change there API to be"},{"line_number":101,"context_line":"one that only really works in the openstack community where the usage of"},{"line_number":102,"context_line":"``ConfigOpts`` is prevalent."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"Those libraries could in theory completely use the ``URL`` object support for"},{"line_number":105,"context_line":"interacting with oslo libraries if it was fully functional and was a true first"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_a67b69bc","line":102,"in_reply_to":"9aa7fdbe_2b01026a","updated":"2014-10-27 22:34:07.000000000","message":"So they read the docs to understand what the \u0027driver_options\u0027 dictionary takes, and the types associated and we put the burden on the consumer to not provide wacky options (and leave it to them to do the needed type validation, if applicable). This seems to be relatively standard with what other libraries do, so I\u0027m not entirely sure that it\u0027s bad (it\u0027s just different).\n\nOne of the reasons for this proposal was to add a way to use oslo libraries from a way which does not force oslo.config everywhere (which allows interacting with oslo libraries that are dependent on oslo.config from libraries that are not). Ie, taskflow ;)\n\nAn example of how this could work (given the following .ini file):\n\n  [default]\n  message_driver \u003d kombu\n  \n  [kombu_driver]\n  \n  timeout \u003d 2\n  hosts \u003d a,b,c\n\nNow to interact with this dictionary type (if desired, vs just passing a ``ConfigOpts`` it would be imaginable for the application to extract the [kombu_driver] section from the config and turn it into a dictionary to be passed on to the thing that creates the driver. If the `kombu_driver `documentation states that \u0027hosts\u0027 should be a list, then it should either be converted, or it should just be passed to the driver and the driver should know how to deal with comma separated strings. This is just one of the thousand/million ways to create a dictionary for the kombu driver to use (none of which force the kombu driver to be aware of configuration options, configuration objects...). The idea though is that its up to the application/library using whatever this kombu driver is to just follow what the driver documentation/docstrings/other states should be the dictionary format and it\u0027s their job to get whatever configuration it has into that format (and not the reverse).\n\nThis seems pretty common in most applications, libraries that I have ever been exposed to (not just in python, but elsewhere...). It\u0027s also slightly interesting that if a https://docs.python.org/2/library/configparser.html was used instead of oslo.config this functionality wouldn\u0027t be needed *as much* (as those objects already support providing dictionaries that are the defaults that a library could populate before interacting with an oslo library that uses a configparser); note that this is still not ideal as the driver API is still not well-defined (passing a configparser which can contain arbitrary things isn\u0027t really a well-defined/well-structured/well-documented API).","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"295a1d50603fd721323851e2d598a757336c5eb5","unresolved":false,"context_lines":[{"line_number":99,"context_line":"openstack are stuck in a rock-and-a-hard place since now they either"},{"line_number":100,"context_line":"have to avoid using the mentioned libraries or change there API to be"},{"line_number":101,"context_line":"one that only really works in the openstack community where the usage of"},{"line_number":102,"context_line":"``ConfigOpts`` is prevalent."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"Those libraries could in theory completely use the ``URL`` object support for"},{"line_number":105,"context_line":"interacting with oslo libraries if it was fully functional and was a true first"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_94b7cfd7","line":102,"in_reply_to":"9aa7fdbe_3b40d9a4","updated":"2014-10-23 02:36:57.000000000","message":"Right, that is part of the problem...\n\nThis seems typically solved by allowing users (libraries or applications) of oslo.messaging (or in the general case with pluggable libraries) to know by looking at documentation what options they should provide to configure there desired driver they want to work with/use. Then it seems common for the dictionary (or **kwargs) to have a top level set of options and maybe a \u0027driver_options\u0027 section that the driver takes its options from. This is at least what it appears kombu and sqlalchemy (and taskflow and tooz) do from what I can tell (maybe others that do similar things to):\n\nhttp://kombu.readthedocs.org/en/latest/userguide/connections.html#keyword-arguments\n\nhttp://docs.sqlalchemy.org/en/rel_0_9/core/engines.html#sqlalchemy.create_engine","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"085e266c6c210b9fb19c07d4f23e694f597b178f","unresolved":false,"context_lines":[{"line_number":99,"context_line":"openstack are stuck in a rock-and-a-hard place since now they either"},{"line_number":100,"context_line":"have to avoid using the mentioned libraries or change there API to be"},{"line_number":101,"context_line":"one that only really works in the openstack community where the usage of"},{"line_number":102,"context_line":"``ConfigOpts`` is prevalent."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"Those libraries could in theory completely use the ``URL`` object support for"},{"line_number":105,"context_line":"interacting with oslo libraries if it was fully functional and was a true first"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_2b01026a","line":102,"in_reply_to":"9aa7fdbe_94b7cfd7","updated":"2014-10-27 21:18:46.000000000","message":"OK, but if we don\u0027t want nova developers to have to code around specific driver options, and they want to use this new API, how would they know what to put into the driver_options sub-dictionary? Are we just moving the burden of defining and validating the options from oslo.messaging to the consumer of oslo.messaging?","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"01280f55164f27308c88442f8ee918302c8afe80","unresolved":false,"context_lines":[{"line_number":103,"context_line":""},{"line_number":104,"context_line":"Those libraries could in theory completely use the ``URL`` object support for"},{"line_number":105,"context_line":"interacting with oslo libraries if it was fully functional and was a true first"},{"line_number":106,"context_line":"class citizen (and not a partially implemented second class citizen)."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"Impact on Existing APIs"},{"line_number":109,"context_line":"-----------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_7b4a61c6","line":106,"updated":"2014-10-22 19:48:35.000000000","message":"Should we just finish that work then?","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"f2ac0d953294dc31df1df81f4ca834eaf916cf93","unresolved":false,"context_lines":[{"line_number":103,"context_line":""},{"line_number":104,"context_line":"Those libraries could in theory completely use the ``URL`` object support for"},{"line_number":105,"context_line":"interacting with oslo libraries if it was fully functional and was a true first"},{"line_number":106,"context_line":"class citizen (and not a partially implemented second class citizen)."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"Impact on Existing APIs"},{"line_number":109,"context_line":"-----------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_d2dec73e","line":106,"in_reply_to":"9aa7fdbe_54dc8712","updated":"2014-10-23 05:31:09.000000000","message":"And an equally weird example:\n\nhttps://github.com/openstack/oslo.messaging/blob/master/oslo/messaging/transport.py#L244\n\nIt appears the transport url there requires a ConfigOpts instance as its required first argument, so the current code is tying itself to ConfigOpts even when using URL objects which is weird (especially weird if the URL objects were supposed to be a replacement for the ConfigOpts way of configuring oslo.messaging). So the messaging API may take 1/5 of its options from URL objects which are themselves configured by ConfigOpts instances or 4/5 of it from an actual ConfigOpts instance...\n\nIs there any docs anywhere on the intention/final goal of the URL objects (?) because as it exists in oslo.messaging it doesn\u0027t quite seem to make sense (why would someone use URL objects that themselves have an internal required ConfigOpts objects over just using the ConfigOpts object directly in the first place...)","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"295a1d50603fd721323851e2d598a757336c5eb5","unresolved":false,"context_lines":[{"line_number":103,"context_line":""},{"line_number":104,"context_line":"Those libraries could in theory completely use the ``URL`` object support for"},{"line_number":105,"context_line":"interacting with oslo libraries if it was fully functional and was a true first"},{"line_number":106,"context_line":"class citizen (and not a partially implemented second class citizen)."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"Impact on Existing APIs"},{"line_number":109,"context_line":"-----------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_54dc8712","line":106,"in_reply_to":"9aa7fdbe_7b4a61c6","updated":"2014-10-23 02:36:57.000000000","message":"Depends on how much u want to break there existing APIs.\n\nThings like https://github.com/openstack/oslo.messaging/blob/master/oslo/messaging/transport.py#L77 or https://github.com/openstack/oslo.messaging/blob/master/oslo/messaging/_executors/base.py#L24 (and probably other locations) for oslo.messaging at least will need to avoid doing that kind of configuration object passing around and instead have either a different API.\n\nI\u0027d be fine with one of the solutions that is a first class citizen that other libraries can use, whichever solution that finally is (this one or the URL one or something else). Note though that a URL object can\u0027t contain hierarchies of options, while dictionary configuration object could in theory contain this (may not be a problem, but if a ConfigOpts registration happens with a \u0027group\u0027 then the URL objects can\u0027t easily map that option, thus becoming a second-class citizen again).","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"085e266c6c210b9fb19c07d4f23e694f597b178f","unresolved":false,"context_lines":[{"line_number":103,"context_line":""},{"line_number":104,"context_line":"Those libraries could in theory completely use the ``URL`` object support for"},{"line_number":105,"context_line":"interacting with oslo libraries if it was fully functional and was a true first"},{"line_number":106,"context_line":"class citizen (and not a partially implemented second class citizen)."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"Impact on Existing APIs"},{"line_number":109,"context_line":"-----------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_eb31ba5a","line":106,"in_reply_to":"9aa7fdbe_d2dec73e","updated":"2014-10-27 21:18:46.000000000","message":"I think the idea was the URL would have enough information in it to connect, but if there were tuning parameters or something they might come from the configuration settings found elsewhere. I don\u0027t know why that options object is required by default.","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"0f092b14ea5a93be7198d6b7dd9249d88967495c","unresolved":false,"context_lines":[{"line_number":103,"context_line":""},{"line_number":104,"context_line":"Those libraries could in theory completely use the ``URL`` object support for"},{"line_number":105,"context_line":"interacting with oslo libraries if it was fully functional and was a true first"},{"line_number":106,"context_line":"class citizen (and not a partially implemented second class citizen)."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"Impact on Existing APIs"},{"line_number":109,"context_line":"-----------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_4628fd99","line":106,"in_reply_to":"9aa7fdbe_eb31ba5a","updated":"2014-10-27 22:34:07.000000000","message":"Interesting, I wonder why an approach like the one mentioned here wasn\u0027t just adopted. Avoid having 2 disjoint APIs (one that takes some basic parameters, but for anything complex, where the definition of complex is arbitrarily defined, use the other one - if u can...)","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"01280f55164f27308c88442f8ee918302c8afe80","unresolved":false,"context_lines":[{"line_number":178,"context_line":"   these methods will actually do at this point is up for discussion)."},{"line_number":179,"context_line":"3. Ensure that for the basic oslo libraries that use the existing"},{"line_number":180,"context_line":"   ``ConfigOpts`` can be passed in a ``DictConfigOpts`` and still continue"},{"line_number":181,"context_line":"   operating correctly using a non-config-file/cli provided options..."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Incubation"},{"line_number":184,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_1b5f9573","line":181,"updated":"2014-10-22 19:48:35.000000000","message":"There is a potentially related discussion about making oslo.config have pluggable backends. That was proposed to allow encryption of some of the settings, but I could see it being useful for this case as well. I think I prefer that as the more general solution, if it can be made to work.","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"085e266c6c210b9fb19c07d4f23e694f597b178f","unresolved":false,"context_lines":[{"line_number":178,"context_line":"   these methods will actually do at this point is up for discussion)."},{"line_number":179,"context_line":"3. Ensure that for the basic oslo libraries that use the existing"},{"line_number":180,"context_line":"   ``ConfigOpts`` can be passed in a ``DictConfigOpts`` and still continue"},{"line_number":181,"context_line":"   operating correctly using a non-config-file/cli provided options..."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Incubation"},{"line_number":184,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_8b482ecd","line":181,"in_reply_to":"9aa7fdbe_14f91f80","updated":"2014-10-27 21:18:46.000000000","message":"Not yet, no. I wouldn\u0027t block this work on that (\u0027m more worried about the concerns I raise above) but it would be good to understand how much work creating a pluggable backend really would be, before adding another branch in the existing code (config file, command line options, now dicts).","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"295a1d50603fd721323851e2d598a757336c5eb5","unresolved":false,"context_lines":[{"line_number":178,"context_line":"   these methods will actually do at this point is up for discussion)."},{"line_number":179,"context_line":"3. Ensure that for the basic oslo libraries that use the existing"},{"line_number":180,"context_line":"   ``ConfigOpts`` can be passed in a ``DictConfigOpts`` and still continue"},{"line_number":181,"context_line":"   operating correctly using a non-config-file/cli provided options..."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Incubation"},{"line_number":184,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_14f91f80","line":181,"in_reply_to":"9aa7fdbe_1b5f9573","updated":"2014-10-23 02:36:57.000000000","message":"Sure. A ``DictConfigOpts`` is just a pluggable backend that uses a dictionary as its plugin \u0027backend\u0027. If that discussion materializes some actual code then I think it\u0027d be fair to go that route. Does that have a spec or code or any materialized stuff yet?","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"0f092b14ea5a93be7198d6b7dd9249d88967495c","unresolved":false,"context_lines":[{"line_number":178,"context_line":"   these methods will actually do at this point is up for discussion)."},{"line_number":179,"context_line":"3. Ensure that for the basic oslo libraries that use the existing"},{"line_number":180,"context_line":"   ``ConfigOpts`` can be passed in a ``DictConfigOpts`` and still continue"},{"line_number":181,"context_line":"   operating correctly using a non-config-file/cli provided options..."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Incubation"},{"line_number":184,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9aa7fdbe_41b2a74c","line":181,"in_reply_to":"9aa7fdbe_8b482ecd","updated":"2014-10-27 22:34:07.000000000","message":"Sure. Agreed.\n\nIdeally if we have a well defined interface that is ``_BaseConfigOpts`` then either should be possible (dict backed one, remote backed one...). A similar set of problems exist for those types of backends as well (although the reason for those existing/being implements is I believe, slightly different).","commit_id":"faa12d8265a66e327d91b8eecbdde5f1eb2c51f6"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"880d9fd7bed200c6c2053ae24676c3358f2bc3d2","unresolved":false,"context_lines":[{"line_number":120,"context_line":"What the 1/5 and what the 4/5 are (and where/why they overlap) is a effort"},{"line_number":121,"context_line":"left up-to the reader to try to figure out (it is not easily determinable what"},{"line_number":122,"context_line":"that split is and what the overlap is either or why it is split like it"},{"line_number":123,"context_line":"currently is...). A possible fix is to finish the URL object support and"},{"line_number":124,"context_line":"maintain 2 APIs for all existing objects, drivers, transports in"},{"line_number":125,"context_line":"oslo.messaging/elsewhere... (this will not be a backwards compatible adjustment"},{"line_number":126,"context_line":"in certain places as certain API\u0027s require and only use a ``ConfigOpts``"}],"source_content_type":"text/x-rst","patch_set":8,"id":"5a890539_2cfa4b75","line":123,"updated":"2014-11-13 20:51:41.000000000","message":"To follow up from comments left on earlier drafts, and from the discussion at the summit: The split between URL options and ConfigOpt options has to do with which values are connection-specific (host, exchange, etc.) and which are common (timeouts, retries, etc.). Moving everything into the URL makes documenting the options more work for everyone in the ecosystem because it bypasses all of the work we\u0027ve done integrating oslo.config with our documentation tool chain.","commit_id":"71d41797ad01037b8fd6357ded669896b225e7a9"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"a435539bd9e5b4e6ba8c6a5944da41eee632552a","unresolved":false,"context_lines":[{"line_number":120,"context_line":"What the 1/5 and what the 4/5 are (and where/why they overlap) is a effort"},{"line_number":121,"context_line":"left up-to the reader to try to figure out (it is not easily determinable what"},{"line_number":122,"context_line":"that split is and what the overlap is either or why it is split like it"},{"line_number":123,"context_line":"currently is...). A possible fix is to finish the URL object support and"},{"line_number":124,"context_line":"maintain 2 APIs for all existing objects, drivers, transports in"},{"line_number":125,"context_line":"oslo.messaging/elsewhere... (this will not be a backwards compatible adjustment"},{"line_number":126,"context_line":"in certain places as certain API\u0027s require and only use a ``ConfigOpts``"}],"source_content_type":"text/x-rst","patch_set":8,"id":"5a890539_df0b268c","line":123,"in_reply_to":"5a890539_2cfa4b75","updated":"2014-11-13 23:43:32.000000000","message":"I agree that having URLs replace all the things won\u0027t work (or it will duplicate the same things in oslo.config), although I would disagree that the split can differentiate between common and connection specific since for some users timeouts and others aren\u0027t common, they may be in openstack applications, but they can\u0027t be assumed to be in other applications and it wouldn\u0027t seem reasonable to assume that.","commit_id":"71d41797ad01037b8fd6357ded669896b225e7a9"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"880d9fd7bed200c6c2053ae24676c3358f2bc3d2","unresolved":false,"context_lines":[{"line_number":149,"context_line":"example the kombu driver in oslo.messaging using the rabbit implementation)"},{"line_number":150,"context_line":"and then provide it to oslo.messaging. This would allow for *full* and *custom*"},{"line_number":151,"context_line":"configuration of that kombu driver (removing any type of configuration logic"},{"line_number":152,"context_line":"from oslo.messaging, allowing it to be solely a messaging library)."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"Impact on Existing APIs"},{"line_number":155,"context_line":"-----------------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"5a890539_0cb4afcf","line":152,"updated":"2014-11-13 20:51:41.000000000","message":"That means every application is going to define those options, though, and that\u0027s definitely not what we want. We are first and foremost building libraries to improve the quality of OpenStack. We can\u0027t ignore or deprioritize that requirement when we look for ways to make those libraries useful to other projects. One of the important ways we can provide value is to make libraries that handle all of the configuration options for the underlying code in one place. That means all of the consumers of the library have consistent configuration option names, validation, and handling. That often means making the API of the library use the application\u0027s configuration object as well, but that\u0027s a feature not a bug in most cases.","commit_id":"71d41797ad01037b8fd6357ded669896b225e7a9"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"880d9fd7bed200c6c2053ae24676c3358f2bc3d2","unresolved":false,"context_lines":[{"line_number":196,"context_line":""},{"line_number":197,"context_line":"It also makes it easy for unit tests that currently exist to provide a"},{"line_number":198,"context_line":"``ConfigOpts`` instance that is backed by a per-test dictionary, which could"},{"line_number":199,"context_line":"be useful for testing purposes..."},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"Testing Impact"},{"line_number":202,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"5a890539_ccce272e","line":199,"updated":"2014-11-13 20:51:41.000000000","message":"We have a test fixture in oslo.config for those cases.","commit_id":"71d41797ad01037b8fd6357ded669896b225e7a9"}],"specs/kilo/proxy-config-opts.rst":[{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"5b27d3e02fa40198e419a0cac719680d0d760d56","unresolved":false,"context_lines":[{"line_number":22,"context_line":"  the ``ConfigOpts`` concepts."},{"line_number":23,"context_line":"* Restricts getting configuration values from some external service/provider,"},{"line_number":24,"context_line":"  since the current implementations of configuration finding in oslo.cfg are"},{"line_number":25,"context_line":"  either from a CLI or a configuration file (and nothing else)."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Problem description"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_059d6859","line":25,"updated":"2014-12-10 23:04:45.000000000","message":"Maybe this should be corrected instead, or will this be unnecessary? (Is it an alternative?)","commit_id":"087d4c9a973d76abc7a58496707e35c81f99565c"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"c13e0f2357905fef6052e458c3be70e499d3f91e","unresolved":false,"context_lines":[{"line_number":22,"context_line":"  the ``ConfigOpts`` concepts."},{"line_number":23,"context_line":"* Restricts getting configuration values from some external service/provider,"},{"line_number":24,"context_line":"  since the current implementations of configuration finding in oslo.cfg are"},{"line_number":25,"context_line":"  either from a CLI or a configuration file (and nothing else)."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Problem description"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_10ecc48e","line":25,"in_reply_to":"3a961159_059d6859","updated":"2014-12-10 23:30:05.000000000","message":"Unsure, i\u0027m confused :-P\n\nI was more of just listing some of my perceived limitations of the current mechanism, ha.","commit_id":"087d4c9a973d76abc7a58496707e35c81f99565c"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"5b27d3e02fa40198e419a0cac719680d0d760d56","unresolved":false,"context_lines":[{"line_number":31,"context_line":"files and CLI arguments. Since a non-zero number of oslo libraries (and"},{"line_number":32,"context_line":"applications) depend on ``oslo.config`` and this style of configuration that"},{"line_number":33,"context_line":"makes it hard to use those libraries from another library that does not itself"},{"line_number":34,"context_line":"provide a API that also exposes ``ConfigOpts``. This makes the usage"},{"line_number":35,"context_line":"of ``ConfigOpts`` viral, which means that all libraries that use"},{"line_number":36,"context_line":"``ConfigOpts`` using libraries must now expose a ``ConfigOpts`` themselves so"},{"line_number":37,"context_line":"that the final application (we can typically assume that somewhere in the line"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_85a87878","line":34,"updated":"2014-12-10 23:04:45.000000000","message":"This sentence has a grammar problem doesn\u0027t make sense to me.","commit_id":"087d4c9a973d76abc7a58496707e35c81f99565c"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"d2ddfff71665a943a69c046d32d7970e05f04794","unresolved":false,"context_lines":[{"line_number":31,"context_line":"files and CLI arguments. Since a non-zero number of oslo libraries (and"},{"line_number":32,"context_line":"applications) depend on ``oslo.config`` and this style of configuration that"},{"line_number":33,"context_line":"makes it hard to use those libraries from another library that does not itself"},{"line_number":34,"context_line":"provide a API that also exposes ``ConfigOpts``. This makes the usage"},{"line_number":35,"context_line":"of ``ConfigOpts`` viral, which means that all libraries that use"},{"line_number":36,"context_line":"``ConfigOpts`` using libraries must now expose a ``ConfigOpts`` themselves so"},{"line_number":37,"context_line":"that the final application (we can typically assume that somewhere in the line"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_6b327df3","line":34,"in_reply_to":"3a961159_85a87878","updated":"2014-12-10 23:39:22.000000000","message":"Agreed, lol.","commit_id":"087d4c9a973d76abc7a58496707e35c81f99565c"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"5b27d3e02fa40198e419a0cac719680d0d760d56","unresolved":false,"context_lines":[{"line_number":35,"context_line":"of ``ConfigOpts`` viral, which means that all libraries that use"},{"line_number":36,"context_line":"``ConfigOpts`` using libraries must now expose a ``ConfigOpts`` themselves so"},{"line_number":37,"context_line":"that the final application (we can typically assume that somewhere in the line"},{"line_number":38,"context_line":"of users of the given library that there will some application that uses these"},{"line_number":39,"context_line":"libraries) that uses these libraries can correctly provide the configuration"},{"line_number":40,"context_line":"files or CLI arguments to configure *all* the contained libraries."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_05b488cf","line":38,"updated":"2014-12-10 23:04:45.000000000","message":"change \"will some\" to \"will be some\"","commit_id":"087d4c9a973d76abc7a58496707e35c81f99565c"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"5b27d3e02fa40198e419a0cac719680d0d760d56","unresolved":false,"context_lines":[{"line_number":73,"context_line":"The current oslo.config code provides a ``ConfigOpts`` class that performs the"},{"line_number":74,"context_line":"majority of operations with regards to reading, registering, importing and"},{"line_number":75,"context_line":"overriding... This class is also the one responsible for reading from and"},{"line_number":76,"context_line":"generation configuration files and/or CLI arguments. The change described"},{"line_number":77,"context_line":"here (protoyped/started @ https://review.openstack.org/#/c/134671/ and"},{"line_number":78,"context_line":"its dependent) will create a derivative of ``ConfigOpts`` that will not have"},{"line_number":79,"context_line":"the methods to read from configuration files, or CLI arguments but will instead"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_651e2cbd","line":76,"updated":"2014-12-10 23:04:45.000000000","message":"change \"generation\" to \"generating\" (or \"generation of\")","commit_id":"087d4c9a973d76abc7a58496707e35c81f99565c"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"5b27d3e02fa40198e419a0cac719680d0d760d56","unresolved":false,"context_lines":[{"line_number":219,"context_line":"in ``ConfigOpts`` so this doesn\u0027t seem like such a good path to go down (it\u0027s"},{"line_number":220,"context_line":"also not such a user friendly API)"},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"Another option is to not do anything, and make it hard to use the"},{"line_number":223,"context_line":"libraries like `oslo.messaging`_ in libraries that do not have strong ties to"},{"line_number":224,"context_line":"``ConfigOpts`` instances. This means that libraries which wish to work in both"},{"line_number":225,"context_line":"the surrounding python community and those that wish to also be useful in"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_e5b4dc83","line":222,"updated":"2014-12-10 23:04:45.000000000","message":"this is not an option.","commit_id":"087d4c9a973d76abc7a58496707e35c81f99565c"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"700652fd2a81ab913915c6ee49ff93de8516438e","unresolved":false,"context_lines":[{"line_number":31,"context_line":"files and CLI arguments. Since a non-zero number of oslo libraries (and"},{"line_number":32,"context_line":"applications) depend on ``oslo.config`` and this style of configuration this"},{"line_number":33,"context_line":"usage makes it hard to use those libraries from another library that does not"},{"line_number":34,"context_line":"itself provide a API that also exposes ``ConfigOpts``. This makes the usage"},{"line_number":35,"context_line":"of ``ConfigOpts`` viral, which means that all libraries that use"},{"line_number":36,"context_line":"``ConfigOpts`` must now expose a ``ConfigOpts`` interfaces themselves so"},{"line_number":37,"context_line":"that the final application (we can typically assume that somewhere in the line"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_69ad3788","line":34,"updated":"2014-12-18 15:46:10.000000000","message":"This sentence still doesn\u0027t make sense... maybe remove \"this usage\"?","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"e0a60221adf19dac7f372cb23a7c958686357db3","unresolved":false,"context_lines":[{"line_number":44,"context_line":"that will be used outside of OpenStack (where there is little/any(?) usage of"},{"line_number":45,"context_line":"the ``ConfigOpts`` style of configuration). This overall makes it hard to use"},{"line_number":46,"context_line":"a library from oslo that has a majority of its API coming from"},{"line_number":47,"context_line":"a ``ConfigOpts`` object (for example `oslo.messaging`_ or"},{"line_number":48,"context_line":"`oslo.concurrency`_)."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"With an ability to have a ``ConfigOpts`` class that doesn\u0027t explicitly tie"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_abe64942","line":47,"updated":"2015-01-02 21:51:53.000000000","message":"I think it\u0027s worth noting that our current policy on oslo.* libs is that they aren\u0027t intended to be usable outside of the OpenStack/oslo.config world.  I realize that this is a problem for something like taskflow that wants to work more broadly and still use oslo libs, but we need to be aware that this is a pretty fundamental change of direction and we may run into some other issues with assumptions that were made in libraries because they were supposed to have a more limited audience.","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"3cd140dc4a77d1cb0981834ebf9ca8bcdd312fa7","unresolved":false,"context_lines":[{"line_number":44,"context_line":"that will be used outside of OpenStack (where there is little/any(?) usage of"},{"line_number":45,"context_line":"the ``ConfigOpts`` style of configuration). This overall makes it hard to use"},{"line_number":46,"context_line":"a library from oslo that has a majority of its API coming from"},{"line_number":47,"context_line":"a ``ConfigOpts`` object (for example `oslo.messaging`_ or"},{"line_number":48,"context_line":"`oslo.concurrency`_)."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"With an ability to have a ``ConfigOpts`` class that doesn\u0027t explicitly tie"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_a5658db0","line":47,"in_reply_to":"3a961159_0262da15","updated":"2015-01-13 22:57:35.000000000","message":"I don\u0027t know if it\u0027s something for this spec, but I\u0027m going to add it as a topic for the next meeting so the policy change gets some visibility beyond a single spec.","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"3528efd1e2f452aee7cf1805f811f13a0450b194","unresolved":false,"context_lines":[{"line_number":44,"context_line":"that will be used outside of OpenStack (where there is little/any(?) usage of"},{"line_number":45,"context_line":"the ``ConfigOpts`` style of configuration). This overall makes it hard to use"},{"line_number":46,"context_line":"a library from oslo that has a majority of its API coming from"},{"line_number":47,"context_line":"a ``ConfigOpts`` object (for example `oslo.messaging`_ or"},{"line_number":48,"context_line":"`oslo.concurrency`_)."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"With an ability to have a ``ConfigOpts`` class that doesn\u0027t explicitly tie"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_05d021c8","line":47,"in_reply_to":"3a961159_a5658db0","updated":"2015-01-13 23:09:04.000000000","message":"Ok dokie, I added it anyway as a \u0027note\u0027","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"7add8e6e04f5a0cf9ef16ed26b70c70dc7281d34","unresolved":false,"context_lines":[{"line_number":44,"context_line":"that will be used outside of OpenStack (where there is little/any(?) usage of"},{"line_number":45,"context_line":"the ``ConfigOpts`` style of configuration). This overall makes it hard to use"},{"line_number":46,"context_line":"a library from oslo that has a majority of its API coming from"},{"line_number":47,"context_line":"a ``ConfigOpts`` object (for example `oslo.messaging`_ or"},{"line_number":48,"context_line":"`oslo.concurrency`_)."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"With an ability to have a ``ConfigOpts`` class that doesn\u0027t explicitly tie"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_0262da15","line":47,"in_reply_to":"3a961159_abe64942","updated":"2015-01-13 21:20:41.000000000","message":"Sure; totally understand; should I highlight this more?","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"e0a60221adf19dac7f372cb23a7c958686357db3","unresolved":false,"context_lines":[{"line_number":55,"context_line":"in a way that does not depend on the existing ``ConfigOpts`` style of"},{"line_number":56,"context_line":"configuration)."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"For example the following libraries exist that do not have the same mechanism"},{"line_number":59,"context_line":"but instead use a variation of a ``driver_options`` arguments/keyword arguments"},{"line_number":60,"context_line":"that get passed to the driver to further configure itself:"},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_4bcde5b6","line":58,"updated":"2015-01-02 21:51:53.000000000","message":"So this is basically the same concept as the dual interface to oslo.db where it can take params from oslo.config or kwargs to a constructor.  On a high level this whole spec is an attempt to codify that pattern into oslo.config so it\u0027s easier to do?\n\nEdit: I see this is addressed below.","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"7add8e6e04f5a0cf9ef16ed26b70c70dc7281d34","unresolved":false,"context_lines":[{"line_number":55,"context_line":"in a way that does not depend on the existing ``ConfigOpts`` style of"},{"line_number":56,"context_line":"configuration)."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"For example the following libraries exist that do not have the same mechanism"},{"line_number":59,"context_line":"but instead use a variation of a ``driver_options`` arguments/keyword arguments"},{"line_number":60,"context_line":"that get passed to the driver to further configure itself:"},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_a27026db","line":58,"in_reply_to":"3a961159_4bcde5b6","updated":"2015-01-13 21:20:41.000000000","message":"Possibly...","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"e0a60221adf19dac7f372cb23a7c958686357db3","unresolved":false,"context_lines":[{"line_number":71,"context_line":"Proposed change"},{"line_number":72,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"The current oslo.config code provides a ``ConfigOpts`` class that performs the"},{"line_number":75,"context_line":"majority of operations with regards to reading, registering, importing and"},{"line_number":76,"context_line":"overriding... This class is also the one responsible for reading from and"},{"line_number":77,"context_line":"generating configuration files and/or CLI arguments. The change described"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_6e6c6f37","line":74,"updated":"2015-01-02 21:51:53.000000000","message":"This description makes me think ConfigOpts is begging for a significant refactor in general.","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"7add8e6e04f5a0cf9ef16ed26b70c70dc7281d34","unresolved":false,"context_lines":[{"line_number":71,"context_line":"Proposed change"},{"line_number":72,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"The current oslo.config code provides a ``ConfigOpts`` class that performs the"},{"line_number":75,"context_line":"majority of operations with regards to reading, registering, importing and"},{"line_number":76,"context_line":"overriding... This class is also the one responsible for reading from and"},{"line_number":77,"context_line":"generating configuration files and/or CLI arguments. The change described"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_224c369d","line":74,"in_reply_to":"3a961159_6e6c6f37","updated":"2015-01-13 21:20:41.000000000","message":"Ya, see reviews below/inline that basically do part of that refactoring ;)","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"e0a60221adf19dac7f372cb23a7c958686357db3","unresolved":false,"context_lines":[{"line_number":144,"context_line":"case that the retriever is a dictionary, it could then clear its own local"},{"line_number":145,"context_line":"copy instead). This would provide a flexible framework for getting away from"},{"line_number":146,"context_line":"always needing to provide a configuration file (or CLI) and in the future could"},{"line_number":147,"context_line":"allow for this ``ProxyConfigOpts`` to be the base class of the existing classes"},{"line_number":148,"context_line":"in ``oslo.config`` (since the retriever in that case could be the thing that"},{"line_number":149,"context_line":"has read or parsed a configuration file or CLI arguments)."},{"line_number":150,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_ee493f8f","line":147,"updated":"2015-01-02 21:51:53.000000000","message":"So I guess to address my refactoring comment above we would add file and cli-based backends to the ProxyConfigOpts and it would essentially replace the existing ConfigOpts at that point?","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"3cd140dc4a77d1cb0981834ebf9ca8bcdd312fa7","unresolved":false,"context_lines":[{"line_number":144,"context_line":"case that the retriever is a dictionary, it could then clear its own local"},{"line_number":145,"context_line":"copy instead). This would provide a flexible framework for getting away from"},{"line_number":146,"context_line":"always needing to provide a configuration file (or CLI) and in the future could"},{"line_number":147,"context_line":"allow for this ``ProxyConfigOpts`` to be the base class of the existing classes"},{"line_number":148,"context_line":"in ``oslo.config`` (since the retriever in that case could be the thing that"},{"line_number":149,"context_line":"has read or parsed a configuration file or CLI arguments)."},{"line_number":150,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_0525815b","line":147,"in_reply_to":"3a961159_c256122a","updated":"2015-01-13 22:57:35.000000000","message":"Right, completely agree.  Some of these comments were me thinking out loud. :-)","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"7add8e6e04f5a0cf9ef16ed26b70c70dc7281d34","unresolved":false,"context_lines":[{"line_number":144,"context_line":"case that the retriever is a dictionary, it could then clear its own local"},{"line_number":145,"context_line":"copy instead). This would provide a flexible framework for getting away from"},{"line_number":146,"context_line":"always needing to provide a configuration file (or CLI) and in the future could"},{"line_number":147,"context_line":"allow for this ``ProxyConfigOpts`` to be the base class of the existing classes"},{"line_number":148,"context_line":"in ``oslo.config`` (since the retriever in that case could be the thing that"},{"line_number":149,"context_line":"has read or parsed a configuration file or CLI arguments)."},{"line_number":150,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_c256122a","line":147,"in_reply_to":"3a961159_ee493f8f","updated":"2015-01-13 21:20:41.000000000","message":"Very much possible; that could be the `coup de grace` (or a later change...) :-P\n\nI\u0027d suggest not adding them to ProxyConfigOpts but to use ProxyConfigOpts and have file/cli (retriever, notifier) that it would use to fetch/notify to...\n\nThat makes it possible for someone to add a new (retriever, notifier) that uses a webservice (https?), or one that uses something else... or a dumb dictionary or ...","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"6a314c6765b0f24abb87756ee8aacb40c3c40d24","unresolved":false,"context_lines":[{"line_number":148,"context_line":"in ``oslo.config`` (since the retriever in that case could be the thing that"},{"line_number":149,"context_line":"has read or parsed a configuration file or CLI arguments)."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"An example that uses this::"},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"    from oslo.config import cfg"},{"line_number":154,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_4b6b011e","line":151,"updated":"2014-12-18 23:03:34.000000000","message":"This looks interesting, but I\u0027m having trouble seeing how it would work in a real case such as a library that doesn\u0027t use oslo.config setting up a library that does. Can you put together an example that shows what calls would go in each of the 2 separate libraries?","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4464b8d57c0eb007bb9bff6f69fa71747e541258","unresolved":false,"context_lines":[{"line_number":148,"context_line":"in ``oslo.config`` (since the retriever in that case could be the thing that"},{"line_number":149,"context_line":"has read or parsed a configuration file or CLI arguments)."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"An example that uses this::"},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"    from oslo.config import cfg"},{"line_number":154,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_32853d07","line":151,"in_reply_to":"3a961159_4b6b011e","updated":"2014-12-19 06:33:39.000000000","message":"Can do.","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"700652fd2a81ab913915c6ee49ff93de8516438e","unresolved":false,"context_lines":[{"line_number":160,"context_line":"            print(\"Group %s was registered\" % group)"},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"        def notify_opt_unregistered(self, config, group\u003dNone):"},{"line_number":163,"context_line":"            print(\"Opt %s was unregistered\" % opt)"},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"        def notify_opt_registered(self, config, opt, group\u003dNone):"},{"line_number":166,"context_line":"            print(\"Opt %s was registered\" % opt)"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_c9154b9c","line":163,"updated":"2014-12-18 15:46:10.000000000","message":"I assume opt is supposed to be an argument to the method?","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4464b8d57c0eb007bb9bff6f69fa71747e541258","unresolved":false,"context_lines":[{"line_number":160,"context_line":"            print(\"Group %s was registered\" % group)"},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"        def notify_opt_unregistered(self, config, group\u003dNone):"},{"line_number":163,"context_line":"            print(\"Opt %s was unregistered\" % opt)"},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"        def notify_opt_registered(self, config, opt, group\u003dNone):"},{"line_number":166,"context_line":"            print(\"Opt %s was registered\" % opt)"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_727a6525","line":163,"in_reply_to":"3a961159_c9154b9c","updated":"2014-12-19 06:33:39.000000000","message":"Hmm, crap, ha. Yes.","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"700652fd2a81ab913915c6ee49ff93de8516438e","unresolved":false,"context_lines":[{"line_number":163,"context_line":"            print(\"Opt %s was unregistered\" % opt)"},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"        def notify_opt_registered(self, config, opt, group\u003dNone):"},{"line_number":166,"context_line":"            print(\"Opt %s was registered\" % opt)"},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"        def notify_cleared(self, config):"},{"line_number":169,"context_line":"            print(\"%s was cleared\" % config)"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_e90cc796","line":166,"updated":"2014-12-18 15:46:10.000000000","message":"I assume opt is supposed to be an argument to the method?","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4464b8d57c0eb007bb9bff6f69fa71747e541258","unresolved":false,"context_lines":[{"line_number":163,"context_line":"            print(\"Opt %s was unregistered\" % opt)"},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"        def notify_opt_registered(self, config, opt, group\u003dNone):"},{"line_number":166,"context_line":"            print(\"Opt %s was registered\" % opt)"},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"        def notify_cleared(self, config):"},{"line_number":169,"context_line":"            print(\"%s was cleared\" % config)"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_9273514d","line":166,"in_reply_to":"3a961159_e90cc796","updated":"2014-12-19 06:33:39.000000000","message":"I think I did get it here ;)","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"700652fd2a81ab913915c6ee49ff93de8516438e","unresolved":false,"context_lines":[{"line_number":264,"context_line":"passing them around throughout the library) work with libraries that do not"},{"line_number":265,"context_line":"have APIs that themselves pass around ``ConfigOpts`` instances. This gives"},{"line_number":266,"context_line":"those libraries which do not have that API the ability to create a"},{"line_number":267,"context_line":"dictionary (or some other proxy) of there own choosing and interact correctly"},{"line_number":268,"context_line":"with the libraries which do have the strong tie to ``ConfigOpts`` instances in"},{"line_number":269,"context_line":"a mostly seamless manner."},{"line_number":270,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a961159_29d16ffb","line":267,"updated":"2014-12-18 15:46:10.000000000","message":"change \"there\" to \"their\"","commit_id":"a15f25bf6f0d75112892099a001dab7bb92ed942"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"98a410a7097585ddc1dfc3937a98f5ab01e544d1","unresolved":false,"context_lines":[{"line_number":223,"context_line":"        # example this could be some xml object, something else...); for this"},{"line_number":224,"context_line":"        # example lets assume this is a dictionary..."},{"line_number":225,"context_line":"        return {"},{"line_number":226,"context_line":"            \u0027/DIR_CLEAN_PERIOD\u0027: 5,"},{"line_number":227,"context_line":"        }"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"    def translating_fetcher(existing_config,"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a6ced46_fa03b6b5","line":226,"updated":"2015-03-24 16:16:10.000000000","message":"If periodic_dir_cleaner() declares a configuration option, the user is going to expect to be able to set that option in their configuration file, aren\u0027t they? So we don\u0027t want the value to come from somewhere else - we want it to come from where the user is setting it along with their other configuration options.","commit_id":"73bd2edea14b2e051de49bbe9affeeafb9b8206f"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"a09f03c91c79de4119b3550620b9a002174911b6","unresolved":false,"context_lines":[{"line_number":223,"context_line":"        # example this could be some xml object, something else...); for this"},{"line_number":224,"context_line":"        # example lets assume this is a dictionary..."},{"line_number":225,"context_line":"        return {"},{"line_number":226,"context_line":"            \u0027/DIR_CLEAN_PERIOD\u0027: 5,"},{"line_number":227,"context_line":"        }"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"    def translating_fetcher(existing_config,"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a6ced46_da75d5cb","line":226,"in_reply_to":"1a6ced46_fa03b6b5","updated":"2015-03-26 00:45:14.000000000","message":"I\u0027d rather have that option come from maybe say a webservice, or zookeeper (a common pattern), or other; so I don\u0027t think we can assume configuration files or that operators always want to use configuration files; allowing it to proxy to elsewhere makes it possible to do this; in this case that proxy goes to a get_my_config function which is just using a dictionary...","commit_id":"73bd2edea14b2e051de49bbe9affeeafb9b8206f"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"98a410a7097585ddc1dfc3937a98f5ab01e544d1","unresolved":false,"context_lines":[{"line_number":231,"context_line":"        # This would translate a request for the above params into a accessor"},{"line_number":232,"context_line":"        # on the \u0027non_oslo_config\u0027 local application config and return the"},{"line_number":233,"context_line":"        # value so that the internals of oslo.config can use it (therefore"},{"line_number":234,"context_line":"        # oslo.config is unaware this has happened)."},{"line_number":235,"context_line":"        try:"},{"line_number":236,"context_line":"            name \u003d name.replace(\"/\", \"\\/\")"},{"line_number":237,"context_line":"            if group is not None:"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a6ced46_fac81676","line":234,"updated":"2015-03-24 16:16:10.000000000","message":"It hides from oslo.config that the thing it is working with isn\u0027t a real ConfigOpts, but it exposes outside of the library what the configuration options are, making them effectively part of the API. We have been trying very hard to avoid that, especially for cases like drivers where the options may not be standard across all of the plugins and where some of those plugins might not even be part of the library that uses the driver (they can be delivered in a separate dist).","commit_id":"73bd2edea14b2e051de49bbe9affeeafb9b8206f"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"a09f03c91c79de4119b3550620b9a002174911b6","unresolved":false,"context_lines":[{"line_number":231,"context_line":"        # This would translate a request for the above params into a accessor"},{"line_number":232,"context_line":"        # on the \u0027non_oslo_config\u0027 local application config and return the"},{"line_number":233,"context_line":"        # value so that the internals of oslo.config can use it (therefore"},{"line_number":234,"context_line":"        # oslo.config is unaware this has happened)."},{"line_number":235,"context_line":"        try:"},{"line_number":236,"context_line":"            name \u003d name.replace(\"/\", \"\\/\")"},{"line_number":237,"context_line":"            if group is not None:"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a6ced46_5d2d5f94","line":234,"in_reply_to":"1a6ced46_fac81676","updated":"2015-03-26 00:45:14.000000000","message":"I\u0027m sort of the opinion that they are effectively already part of the API by being things that can be configured via real ``ConfigOpts``; we can believe/try to tell ourself they aren\u0027t but IMHO they are.\n\nLet\u0027s take a comparison to C:\n\n  void add_things(config * cfg, int a, int b) {\n        return a + b + cfg-\u003ec + cfg-\u003e d ...;\n  }\n\nJust because we hide things behind a ``config*`` in the above doesn\u0027t make the actual usage of ``cfg-\u003ec`` any less of a real API that exists; it just hides things (and \u0027c\u0027 and \u0027d\u0027 listed above are still part of how the function operates, and affect it; so are therefore IMHO part of the API; but are now just hidden behind another layer that is this config * object). To me the above is like we are doing with ``ConfigOpts`` (consider the config* pointer equivalent to a ``ConfigOpts`` object), hiding behind it instead of just accepting that \u0027c\u0027 and \u0027d\u0027 are really part of the API (even if indirectly) since they affect how the function above works \u0026 requires (and the function won\u0027t work with a config object that doesn\u0027t have those properties, and in c it would likely segfault; so if the function won\u0027t work without those \u0027c\u0027 and \u0027d\u0027 properties on its config pointer then they really are part of the API).\n\nU could even have this degenerate to:\n\n  void add_things(config * cfg) {\n        return my_cfg-\u003ea + my_cfg-\u003eb + my_cfg-\u003ec + my_cfg -\u003e d ...;\n  }\n\nOr:\n\n  void add_things(int a, int b, int c, int d) {\n        return a + b + c + d;\n  }\n\nWhich is more easy to figure out whats going on? I\u0027m of the opinion that the last one is is (I\u0027m also of the opinion that the final one is easier for developers to read, has less side-effects/external influences ..., easier to understand, it also does not require those same developers to jump to the documentation on ``config *`` and figure out what properties it has, and which are optional/required, as that information is built right into the function signature...).","commit_id":"73bd2edea14b2e051de49bbe9affeeafb9b8206f"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"c6ac50615189f48aab686851bf5b6e9fd52fe4c9","unresolved":false,"context_lines":[{"line_number":246,"context_line":"     # Now to use this existing oslo.config function/library..."},{"line_number":247,"context_line":"     c \u003d cfg.ProxyConfigOpts("},{"line_number":248,"context_line":"        functools.partial(translating_fetcher, get_my_config()))"},{"line_number":249,"context_line":"     periodic_dir_cleaner(c)"},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"Alternatives"},{"line_number":252,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":14,"id":"3a961159_c2b71d20","line":249,"updated":"2015-01-20 20:21:07.000000000","message":"TypeError: periodic_dir_cleaner() takes exactly 2 arguments (1 given)\n\nI get the idea though. ;-)","commit_id":"73bd2edea14b2e051de49bbe9affeeafb9b8206f"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"a73b1003355404339adab8a1fb2dd9ae2f40724a","unresolved":false,"context_lines":[{"line_number":246,"context_line":"     # Now to use this existing oslo.config function/library..."},{"line_number":247,"context_line":"     c \u003d cfg.ProxyConfigOpts("},{"line_number":248,"context_line":"        functools.partial(translating_fetcher, get_my_config()))"},{"line_number":249,"context_line":"     periodic_dir_cleaner(c)"},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"Alternatives"},{"line_number":252,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_1b897926","line":249,"in_reply_to":"3a961159_c2b71d20","updated":"2015-01-22 18:30:13.000000000","message":"U are the best compiler ever :)","commit_id":"73bd2edea14b2e051de49bbe9affeeafb9b8206f"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"98a410a7097585ddc1dfc3937a98f5ab01e544d1","unresolved":false,"context_lines":[{"line_number":286,"context_line":"one that only really works in the OpenStack community where the usage of"},{"line_number":287,"context_line":"``ConfigOpts`` is prevalent (or those libraries have to have functionality"},{"line_number":288,"context_line":"like in ``oslo.db`` to do the appropriate translation from ``ConfigOpts`` to"},{"line_number":289,"context_line":"API args/kwargs)."},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Impact on Existing APIs"},{"line_number":292,"context_line":"-----------------------"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a6ced46_7a36e653","line":289,"updated":"2015-03-24 16:16:10.000000000","message":"As we\u0027re moving more and more of the driver implementation from oslo.messaging and relying on Kombu, and oslo.db is really a configuration wrapper around sqlalchemy, I\u0027m beginning to think that maybe we shouldn\u0027t be trying to put oslo.db and oslo.messaging calls in taskflow, Having a set of libraries that is clearly reusable outside of OpenStack, and a bunch that are just for implementation patterns we use inside of OpenStack, feels like a reasonable trade-off.","commit_id":"73bd2edea14b2e051de49bbe9affeeafb9b8206f"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"a09f03c91c79de4119b3550620b9a002174911b6","unresolved":false,"context_lines":[{"line_number":286,"context_line":"one that only really works in the OpenStack community where the usage of"},{"line_number":287,"context_line":"``ConfigOpts`` is prevalent (or those libraries have to have functionality"},{"line_number":288,"context_line":"like in ``oslo.db`` to do the appropriate translation from ``ConfigOpts`` to"},{"line_number":289,"context_line":"API args/kwargs)."},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Impact on Existing APIs"},{"line_number":292,"context_line":"-----------------------"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a6ced46_7d569bcf","line":289,"in_reply_to":"1a6ced46_7a36e653","updated":"2015-03-26 00:45:14.000000000","message":"I\u0027m of this opinion also.\n\nI like oslo.db being a configuration wrapper. Oslo.messaging is the odd one in the bucket IMHO, as it is part of oslo, but is not just a configuration wrapper but instead is some kind of hybrid of messaging library, configuration wrapper, messaging drivers and a bunch of other things (about half to 3/4 of which just wraps another messaging library, that being kombu). Perhaps as more gets absorbed by kombu this goes away, but idk.\n\nhttps://github.com/ceelian/callme is similar to oslo.messaging but does not try to be the configuration part; perhaps a refactor of oslo.messaging is in order to try to carve out something like \u0027callme\u0027 (the oslo.messaging driver parts, the patterns it provides) and then have oslo.messaging use that (https://github.com/celery/kombu/issues/430 was a similar kind of request to this; that could be possible); having oslo.* libraries be just the configuration part and let other external/non oslo.* libraries be the things that have the patterns/logic (and which are made to be consumeable outside of openstack, for usage by the greater world...)","commit_id":"73bd2edea14b2e051de49bbe9affeeafb9b8206f"}]}