)]}'
{"specs/pike/machine-readable-sample-config.rst":[{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"61d28e35b17e325c0f01cee8da982ca085ac7b85","unresolved":false,"context_lines":[{"line_number":29,"context_line":"is not easily machine-readable.  The content is all written in commented"},{"line_number":30,"context_line":"blocks which would have to be parsed by a deployment tool.  Since that"},{"line_number":31,"context_line":"comment format is not guaranteed to remain the same, it would require ongoing"},{"line_number":32,"context_line":"maintenance by each deployment tool using this approach."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"Proposed change"},{"line_number":35,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_65b75d3a","line":32,"updated":"2017-03-03 13:51:58.000000000","message":"ongoing maintenance *and* configs versioning? (just to clarify)","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"a1c654213d4bcbd212a7fd9dbebda6fd058e930a","unresolved":false,"context_lines":[{"line_number":29,"context_line":"is not easily machine-readable.  The content is all written in commented"},{"line_number":30,"context_line":"blocks which would have to be parsed by a deployment tool.  Since that"},{"line_number":31,"context_line":"comment format is not guaranteed to remain the same, it would require ongoing"},{"line_number":32,"context_line":"maintenance by each deployment tool using this approach."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"Proposed change"},{"line_number":35,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_cde02899","line":32,"in_reply_to":"ba2be162_65b75d3a","updated":"2017-03-03 17:16:58.000000000","message":"Well, I think most deployment tools are branched such that they don\u0027t have to explicitly version their configs.  At least that wasn\u0027t a problem mentioned in the PTG session about this.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"5a843500b44932e9eefde22bdb410d706c444fee","unresolved":false,"context_lines":[{"line_number":43,"context_line":"    DEFAULT:"},{"line_number":44,"context_line":"        image_service:"},{"line_number":45,"context_line":"            # The list of parameters is for example only.  The actual output"},{"line_number":46,"context_line":"            # can include anything deployment tools would find useful."},{"line_number":47,"context_line":"            default: nova.image.glance.GlanceImageService"},{"line_number":48,"context_line":"            documentation: Service used to search for and retrieve images."},{"line_number":49,"context_line":"            type: string"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_40da47e9","line":46,"updated":"2017-03-03 15:03:47.000000000","message":"We should include every property passed to Opt() or OptType() to define the option. There\u0027s no sense in leaving something out that we\u0027ll just have to add back later. Including the type\u0027s parameters will let us capture things like min and max for numerical values.\n\nWe should also clearly document the schema for the file somewhere (not in this spec, necessarily) so a consumer of the data can understand not just what the values are but what types they might see.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"a1c654213d4bcbd212a7fd9dbebda6fd058e930a","unresolved":false,"context_lines":[{"line_number":43,"context_line":"    DEFAULT:"},{"line_number":44,"context_line":"        image_service:"},{"line_number":45,"context_line":"            # The list of parameters is for example only.  The actual output"},{"line_number":46,"context_line":"            # can include anything deployment tools would find useful."},{"line_number":47,"context_line":"            default: nova.image.glance.GlanceImageService"},{"line_number":48,"context_line":"            documentation: Service used to search for and retrieve images."},{"line_number":49,"context_line":"            type: string"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_2d42a468","line":46,"in_reply_to":"ba2be162_40da47e9","updated":"2017-03-03 17:16:58.000000000","message":"Agreed for the most part, although I\u0027m not sure something like \u0027dest\u0027 makes sense in this context, which is why I didn\u0027t just say everything here.  I guess it won\u0027t hurt to include that though, and since it\u0027s not targeted at human consumption the tools can just ignore anything that doesn\u0027t make sense for them.\n\nWe definitely need to document the structure.  I\u0027ll add that to the documentation section.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"5a843500b44932e9eefde22bdb410d706c444fee","unresolved":false,"context_lines":[{"line_number":83,"context_line":"align with the previous config, which should make it easier to transition"},{"line_number":84,"context_line":"from release to release.  These opts would, of course, be marked deprecated so"},{"line_number":85,"context_line":"it is clear that they should no longer be used.  An example of this is included"},{"line_number":86,"context_line":"above."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Note on the implementation: In order to easily support both YAML and JSON"},{"line_number":89,"context_line":"formats, I think the generator should work with nested dicts that can simply"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_a032230e","line":86,"updated":"2017-03-03 15:03:47.000000000","message":"Can you elaborate on why this is easier? It seems likely to lead to mistakes like using the old name even though something has been deprecated.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"ec6c0dda3dabb18aa651e71a73c73bfd5d452054","unresolved":false,"context_lines":[{"line_number":83,"context_line":"align with the previous config, which should make it easier to transition"},{"line_number":84,"context_line":"from release to release.  These opts would, of course, be marked deprecated so"},{"line_number":85,"context_line":"it is clear that they should no longer be used.  An example of this is included"},{"line_number":86,"context_line":"above."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Note on the implementation: In order to easily support both YAML and JSON"},{"line_number":89,"context_line":"formats, I think the generator should work with nested dicts that can simply"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_bc67a0b5","line":86,"in_reply_to":"ba2be162_10c17354","updated":"2017-03-03 18:26:51.000000000","message":"Maybe that info can go into a separate section of the file. So you\u0027d have a top level \"current-options\" section with what you have now and then a \"deprecated-options\" section that maps old names to their new locations.\n\nAdding another level to the file structure would also let us capture information like the inputs to the generator and the versions of everything, which might not be useful most of the time but could really help with debugging if there are issues. For example, options in out-of-tree drivers won\u0027t be included unless the code is installed when the generator runs.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"a1c654213d4bcbd212a7fd9dbebda6fd058e930a","unresolved":false,"context_lines":[{"line_number":83,"context_line":"align with the previous config, which should make it easier to transition"},{"line_number":84,"context_line":"from release to release.  These opts would, of course, be marked deprecated so"},{"line_number":85,"context_line":"it is clear that they should no longer be used.  An example of this is included"},{"line_number":86,"context_line":"above."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Note on the implementation: In order to easily support both YAML and JSON"},{"line_number":89,"context_line":"formats, I think the generator should work with nested dicts that can simply"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_10c17354","line":86,"in_reply_to":"ba2be162_a032230e","updated":"2017-03-03 17:16:58.000000000","message":"My thought was that if you\u0027re representing the config data internally in some sort of structure that parallels the one proposed here then it\u0027s a little easier to look up opt_data[\u0027DEFAULT\u0027][\u0027old_opt\u0027] and check for deprecated: True than to look up the opt, not find it, and have to search all of the other opts to figure out which one deprecated it.\n\nI guess the example isn\u0027t quite right either.  The deprecated opt would also have a replacement_name/group to point at the new, undeprecated opt.  Basically there would be a two-way mapping between deprecated opts and their replacements so the lookup can be done in either direction easily.\n\nThat said, this would be an additive change so it\u0027s something we could add after the initial implementation if desired.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"f92b29be477f031b8035b0eda2ff1f934f8e4351","unresolved":false,"context_lines":[{"line_number":83,"context_line":"align with the previous config, which should make it easier to transition"},{"line_number":84,"context_line":"from release to release.  These opts would, of course, be marked deprecated so"},{"line_number":85,"context_line":"it is clear that they should no longer be used.  An example of this is included"},{"line_number":86,"context_line":"above."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Note on the implementation: In order to easily support both YAML and JSON"},{"line_number":89,"context_line":"formats, I think the generator should work with nested dicts that can simply"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_0094be40","line":86,"in_reply_to":"ba2be162_bc67a0b5","updated":"2017-03-03 19:08:52.000000000","message":"Yeah, I had actually brought up something similar when Emilien and I were getting started on the spec.  I didn\u0027t include it because I wasn\u0027t sure a completely separate section was necessary, but your point about being able to put other useful information in if we add a layer on top of the options is a good one.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"5a843500b44932e9eefde22bdb410d706c444fee","unresolved":false,"context_lines":[{"line_number":88,"context_line":"Note on the implementation: In order to easily support both YAML and JSON"},{"line_number":89,"context_line":"formats, I think the generator should work with nested dicts that can simply"},{"line_number":90,"context_line":"be output using the appropriate module.  Since YAML and JSON formatters"},{"line_number":91,"context_line":"already exist we shouldn\u0027t need to reinvent those wheels."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"},{"line_number":94,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_402407c4","line":91,"updated":"2017-03-03 15:03:47.000000000","message":"Why do we need to produce JSON output?","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":3153,"name":"Emilien Macchi","email":"emilien@redhat.com","username":"emilienm"},"change_message_id":"56238f588a3cee2a554b041f8444bff001c9231f","unresolved":false,"context_lines":[{"line_number":88,"context_line":"Note on the implementation: In order to easily support both YAML and JSON"},{"line_number":89,"context_line":"formats, I think the generator should work with nested dicts that can simply"},{"line_number":90,"context_line":"be output using the appropriate module.  Since YAML and JSON formatters"},{"line_number":91,"context_line":"already exist we shouldn\u0027t need to reinvent those wheels."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"},{"line_number":94,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_30ae7781","line":91,"in_reply_to":"ba2be162_402407c4","updated":"2017-03-03 17:09:48.000000000","message":"I think YAML would be a first start.\nWe mentioned JSON at the PTG just for example but we agreed with YAML.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"a1c654213d4bcbd212a7fd9dbebda6fd058e930a","unresolved":false,"context_lines":[{"line_number":88,"context_line":"Note on the implementation: In order to easily support both YAML and JSON"},{"line_number":89,"context_line":"formats, I think the generator should work with nested dicts that can simply"},{"line_number":90,"context_line":"be output using the appropriate module.  Since YAML and JSON formatters"},{"line_number":91,"context_line":"already exist we shouldn\u0027t need to reinvent those wheels."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"},{"line_number":94,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_90948343","line":91,"in_reply_to":"ba2be162_402407c4","updated":"2017-03-03 17:16:58.000000000","message":"I\u0027m not sure we do.  I mostly figured it wouldn\u0027t be difficult to support both since one is a subset of the other.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"ec6c0dda3dabb18aa651e71a73c73bfd5d452054","unresolved":false,"context_lines":[{"line_number":88,"context_line":"Note on the implementation: In order to easily support both YAML and JSON"},{"line_number":89,"context_line":"formats, I think the generator should work with nested dicts that can simply"},{"line_number":90,"context_line":"be output using the appropriate module.  Since YAML and JSON formatters"},{"line_number":91,"context_line":"already exist we shouldn\u0027t need to reinvent those wheels."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"},{"line_number":94,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_bc15e0e5","line":91,"in_reply_to":"ba2be162_66975948","updated":"2017-03-03 18:26:51.000000000","message":"OK, as I pointed out below with the policy generator we went straight to YAML. I\u0027d rather we stick to one format here, too, since it reduces testing. Is JSON easier for the existing tools to consume, or can we just use YAML?","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"a4cc002ce85c7b21ddf5ccbb2d0d76ee08ae882d","unresolved":false,"context_lines":[{"line_number":88,"context_line":"Note on the implementation: In order to easily support both YAML and JSON"},{"line_number":89,"context_line":"formats, I think the generator should work with nested dicts that can simply"},{"line_number":90,"context_line":"be output using the appropriate module.  Since YAML and JSON formatters"},{"line_number":91,"context_line":"already exist we shouldn\u0027t need to reinvent those wheels."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"},{"line_number":94,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_66975948","line":91,"in_reply_to":"ba2be162_90948343","updated":"2017-03-03 17:42:30.000000000","message":"As far as I recall we all wanted JSON, but thought that YAML would be trivial to also do if JSON was done. Ultimately I don\u0027t think the format matters, as long as it\u0027s not designed to be parsed by humans.\n\nOf course the irony here is the INI was designed to be machine parsable.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"f289006114eb8ab326279cb7151da539ef709b76","unresolved":false,"context_lines":[{"line_number":88,"context_line":"Note on the implementation: In order to easily support both YAML and JSON"},{"line_number":89,"context_line":"formats, I think the generator should work with nested dicts that can simply"},{"line_number":90,"context_line":"be output using the appropriate module.  Since YAML and JSON formatters"},{"line_number":91,"context_line":"already exist we shouldn\u0027t need to reinvent those wheels."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"},{"line_number":94,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9a30ddce_9932e3a5","line":91,"in_reply_to":"ba2be162_bc15e0e5","updated":"2017-03-10 17:57:45.000000000","message":"I don\u0027t personally have any strong opinions one way or another on format, which is why I sat on the fence and said let\u0027s do both.  As I recall, we went with YAML for the policy generator so we could have comments, but comments aren\u0027t going to be useful in this context.  In fact, I wonder if we should exlicitly avoid having comments in these files.  Any information that might be needed should be part of the data structure.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"61d28e35b17e325c0f01cee8da982ca085ac7b85","unresolved":false,"context_lines":[{"line_number":90,"context_line":"be output using the appropriate module.  Since YAML and JSON formatters"},{"line_number":91,"context_line":"already exist we shouldn\u0027t need to reinvent those wheels."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"},{"line_number":94,"context_line":"------------"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Some of the existing methods for doing this and their drawbacks are discussed"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_65567d2b","line":93,"updated":"2017-03-03 13:51:58.000000000","message":"Instead of (or additionally to) YAML/JSON files as a single source of truth, we could leverage a KV storage and \"schemaless\" architecture, like Kubernetes\u0027s /registry in etcd.\n\nThis makes configuration not only machine-readable but machine-writable/watchable/triggerable/auto-discovery-able etc.!\n\nFor example, if some service wanted to checkpoint its runtime config into a permanent YAML/JSON file, it could invoke some oslo.config\u0027s API call to export the required configuration from a particular /registry path. The result then looks the same way as you described in the spec, but the single source of truth is just not the config files, but KVS entries.\n\nActually, I\u0027d call my vote for that alternative, although I\u0027m biased to the Kubernetes with etcd architecture.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"32128d846d558e89562d7214ad1afffa99be4bcf","unresolved":false,"context_lines":[{"line_number":90,"context_line":"be output using the appropriate module.  Since YAML and JSON formatters"},{"line_number":91,"context_line":"already exist we shouldn\u0027t need to reinvent those wheels."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"},{"line_number":94,"context_line":"------------"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Some of the existing methods for doing this and their drawbacks are discussed"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_8627f8c8","line":93,"in_reply_to":"ba2be162_65567d2b","updated":"2017-03-03 14:26:30.000000000","message":"Yes, the KV storage thing has been raised as a secondary initiative to explore in https://etherpad.openstack.org/p/deployment-pike\n\nThis particular spec is a starting point, whereas instrumenting service config from a KV store is an evolution from here. I would recommend that we keep this scope small and simple.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":3153,"name":"Emilien Macchi","email":"emilien@redhat.com","username":"emilienm"},"change_message_id":"ebd0fd9605f909cfc9d0590b6f84d133714410c7","unresolved":false,"context_lines":[{"line_number":90,"context_line":"be output using the appropriate module.  Since YAML and JSON formatters"},{"line_number":91,"context_line":"already exist we shouldn\u0027t need to reinvent those wheels."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"},{"line_number":94,"context_line":"------------"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Some of the existing methods for doing this and their drawbacks are discussed"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_8c4d5940","line":93,"in_reply_to":"ba2be162_8627f8c8","updated":"2017-03-03 14:56:22.000000000","message":"Like Jesse said, this spec is a first iteration on the next gen for configuration management in OpenStack. We\u0027re working through baby steps and this spec is the first one.\n\nAt the PTG, we discussed about what you say here and we agree that\u0027s a valuable option for the future. The main blocker now is that most of deployment tools (TripleO, OSA, Fuel, Kolla) don\u0027t use etcd architecture now. Until we move there, we would like this spec so we can move forward and continue the investigation. Does it make sense?","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"5a7f1f0bf271a7294c1c45abb53f4c3fb052e368","unresolved":false,"context_lines":[{"line_number":90,"context_line":"be output using the appropriate module.  Since YAML and JSON formatters"},{"line_number":91,"context_line":"already exist we shouldn\u0027t need to reinvent those wheels."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Alternatives"},{"line_number":94,"context_line":"------------"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Some of the existing methods for doing this and their drawbacks are discussed"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_c101cf07","line":93,"in_reply_to":"ba2be162_8c4d5940","updated":"2017-03-03 18:11:34.000000000","message":"Yes, that makes sense. Let\u0027s just make sure the design fits that world view w/o a need to redesign later.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"5a843500b44932e9eefde22bdb410d706c444fee","unresolved":false,"context_lines":[{"line_number":117,"context_line":"time.  If this feature must be enabled manually, that would require patching"},{"line_number":118,"context_line":"the spec files for every OpenStack project to generate the new formats.  If it"},{"line_number":119,"context_line":"is enabled by default, the packages just need to be rebuilt with the new"},{"line_number":120,"context_line":"config generator."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"Security impact"},{"line_number":123,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_6c9ca55d","line":120,"updated":"2017-03-03 15:03:47.000000000","message":"How would this work? The argument to the generator is the name of an output file, and the default is stdout. Are you proposing to change the command line interface of the generator and its default behavior to write to a set of files instead? I think that\u0027s going to prove more complicated for other users of the tool than updating the spec files to invoke the tool twice with different arguments.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"a1c654213d4bcbd212a7fd9dbebda6fd058e930a","unresolved":false,"context_lines":[{"line_number":117,"context_line":"time.  If this feature must be enabled manually, that would require patching"},{"line_number":118,"context_line":"the spec files for every OpenStack project to generate the new formats.  If it"},{"line_number":119,"context_line":"is enabled by default, the packages just need to be rebuilt with the new"},{"line_number":120,"context_line":"config generator."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"Security impact"},{"line_number":123,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_700e2f3c","line":120,"in_reply_to":"ba2be162_6c9ca55d","updated":"2017-03-03 17:16:58.000000000","message":"Hmm, I didn\u0027t realize we default to stdout.  That does make this behavior problematic.  I agree that we don\u0027t want to change the behavior of the tool so we\u0027ll just have to update the consumers to generate the new format.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"5a843500b44932e9eefde22bdb410d706c444fee","unresolved":false,"context_lines":[{"line_number":138,"context_line":"whether the new formats are enabled by default.  This will require a new option"},{"line_number":139,"context_line":"for the config generator.  I would propose a --formats option that can take a"},{"line_number":140,"context_line":"list of formats to generate.  Or --format, which can be specified multiple"},{"line_number":141,"context_line":"times to output multiple formats.  Whichever is easier to implement."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"Developer Impact"},{"line_number":144,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_2c0b8d8f","line":141,"updated":"2017-03-03 15:03:47.000000000","message":"See the note above. I think it\u0027s going to be easier to use the tool if --format takes a single format and the output option isn\u0027t changed at all.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"5a843500b44932e9eefde22bdb410d706c444fee","unresolved":false,"context_lines":[{"line_number":174,"context_line":"----------"},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"* Implement YAML output"},{"line_number":177,"context_line":"* Implement JSON output"},{"line_number":178,"context_line":"* Add test scenarios for new formats"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Incubation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_6c38253e","line":177,"updated":"2017-03-03 15:03:47.000000000","message":"When we made the switch to YAML in the policy library, we decided to only generate YAML. I think we can do the same in this case.","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"a1c654213d4bcbd212a7fd9dbebda6fd058e930a","unresolved":false,"context_lines":[{"line_number":217,"context_line":"https://github.com/alanmeadows/gen-oslo-openstack-helm"},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"`Cross-Deployment Tool PTG Session"},{"line_number":220,"context_line":"\u003chttps://etherpad.openstack.org/p/ansible-config-mgt\u003e`_, specifically the"},{"line_number":221,"context_line":"Problem #1 section."},{"line_number":222,"context_line":""},{"line_number":223,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2be162_c318f777","line":220,"updated":"2017-03-03 17:16:58.000000000","message":"Oops, apparently I didn\u0027t realize I had already included a link to this. :-)","commit_id":"1e25b1413ae9c16df83ea0edd2617bd9589df57e"}]}