)]}'
{"guidelines/headers.rst":[{"author":{"_account_id":2506,"name":"devdatta-kulkarni","email":"kulkarni.devdatta@gmail.com","username":"devdatta-kulkarni"},"change_message_id":"2feea5935dd9654cab1b34ca47a9e618f9ba2c2c","unresolved":false,"context_lines":[{"line_number":91,"context_line":"Avoid Redundancy in Header Values"},{"line_number":92,"context_line":"---------------------------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"If the name of a header explains what the value is (by virtue of the"},{"line_number":95,"context_line":"name) there is no need to explain again in the value of the header."},{"line_number":96,"context_line":"Compare the following::"},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1af94dfe_3edc6172","line":94,"updated":"2016-03-17 21:48:48.000000000","message":"Makes sense.\n\nIn the particular case of request header, I am wondering why did the use of \u0027req\u0027 prefix start in the first place? Was it because the request header value is a UUID, and somewhere deep in the code there was a need to distinguish request UUIDs from other entities that have a UUID, and there was no access to http headers?","commit_id":"4787d4b459ad24f309e2fdbd3b8459efb70fed9b"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"fda7d0e95154b0f695809bcd38818c6ce9a8dbdb","unresolved":false,"context_lines":[{"line_number":102,"context_line":"   used here because this is the form of a real header generated by"},{"line_number":103,"context_line":"   ``oslo.middleware``."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"In this case the header has already said that the value is a"},{"line_number":106,"context_line":"request ID. Additionally since the value is a UUID there is no need"},{"line_number":107,"context_line":"to put it in a namespace."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1af94dfe_f514dc4d","line":105,"range":{"start_line":105,"start_character":0,"end_line":105,"end_character":12},"updated":"2016-03-17 20:58:40.000000000","message":"I needed time to understand this example. Maybe here says the value doesn\u0027t need to include \"req-\" because of the header name, right?","commit_id":"4787d4b459ad24f309e2fdbd3b8459efb70fed9b"},{"author":{"_account_id":2537,"name":"Nikhil Komawar","email":"nik.komawar@gmail.com","username":"nikhil-komawar"},"change_message_id":"e5e8f13b1e9022b82ad66096c1bff6977067bcc4","unresolved":false,"context_lines":[{"line_number":103,"context_line":"   ``oslo.middleware``."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"In this case the header has already said that the value is a"},{"line_number":106,"context_line":"request ID: the use of \"req\" in the value to indicate \"request\" is"},{"line_number":107,"context_line":"redundant. Additionally since the value is a UUID there is no need"},{"line_number":108,"context_line":"to put it in a namespace."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a061dce_a5a229ac","line":106,"range":{"start_line":106,"start_character":24,"end_line":106,"end_character":27},"updated":"2016-04-06 21:25:57.000000000","message":"I believe there\u0027s some value this having this prefix. For example:\n\n1. an operator may want to log this information and index all of that in something like a ELK\n\n1.1. you want search on the logs that prefix with req- and make it easier to profile/analyze the requests\n\n2. alternatively, if you\u0027re merely grep-ing on log files to find all the requests this prefix is useful\n\nWhat are the best practices here?","commit_id":"8126416f823a7cefaefba261a1cf29aac88fb859"},{"author":{"_account_id":2750,"name":"Sean Dague","email":"sean@dague.net","username":"sdague"},"change_message_id":"904ea7351e196a93ccc67e7f6c72cb2cb9de69cc","unresolved":false,"context_lines":[{"line_number":103,"context_line":"   ``oslo.middleware``."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"In this case the header has already said that the value is a"},{"line_number":106,"context_line":"request ID: the use of \"req\" in the value to indicate \"request\" is"},{"line_number":107,"context_line":"redundant. Additionally since the value is a UUID there is no need"},{"line_number":108,"context_line":"to put it in a namespace."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a061dce_b4f15998","line":106,"in_reply_to":"9a061dce_76b50930","updated":"2016-04-08 10:55:56.000000000","message":"The concerns I see are as follows:\n\nWhen we point to a thing in the code (X) that isn\u0027t ideal, there are multiple audiences that are going to see it.\n\nA) existing projects that did that\nB) new projects coming on board adding things\n\nThere are 2 subsets of group A. Those that will consider this water under the bridge, and A\u0027 that will change a thing because they would like to be in alignment with the spec.\n\nThere is also group B which is writing from scratch, and sees this, and assumes X\u0027 was the better approach. Which means we go from not ideal but consistent (only X), to inconsistent (some X and X\u0027 regardless).\n\nInconsistent is worse than not ideal. So when we are pointing at items like this they should either be not ideal enough that we really want the API WG to work on moving from X -\u003e X\u0027 across the board, or not really talk about this case because everyone doing X is better than people doing X \u0026 X\u0027 (and X\u0027\u0027 when a new group shows up, sees the inconsistency, and thinks they have a new better way to solve it).\n\nThere is also a concern I have with the API WG getting way out ahead of where projects are, so the gulf between what\u0027s here and what\u0027s in projects is basically just always growing. Once it gets too large, projects just write off the API WG because it\u0027s not created years of unfunded mandates. We need to start closing some of the gaps as well as pointing out new ones.","commit_id":"8126416f823a7cefaefba261a1cf29aac88fb859"},{"author":{"_account_id":8246,"name":"Qiming Teng","email":"tengqm@outlook.com","username":"tengqm"},"change_message_id":"b7c0c984ba3dc4dcc53220ee3d26ec2deb13720c","unresolved":false,"context_lines":[{"line_number":103,"context_line":"   ``oslo.middleware``."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"In this case the header has already said that the value is a"},{"line_number":106,"context_line":"request ID: the use of \"req\" in the value to indicate \"request\" is"},{"line_number":107,"context_line":"redundant. Additionally since the value is a UUID there is no need"},{"line_number":108,"context_line":"to put it in a namespace."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a061dce_db4c55ca","line":106,"range":{"start_line":106,"start_character":24,"end_line":106,"end_character":27},"in_reply_to":"9a061dce_a5a229ac","updated":"2016-04-07 02:12:01.000000000","message":"you can grep \u0027OpenStack-Request-ID: df953b\u0027 instead? The header key is crystal clear about the content, so \u0027req-\u0027 is really unnecessary, I believe.","commit_id":"8126416f823a7cefaefba261a1cf29aac88fb859"},{"author":{"_account_id":2750,"name":"Sean Dague","email":"sean@dague.net","username":"sdague"},"change_message_id":"630e0c264046e4f1dd7041e5a8b602300de4382f","unresolved":false,"context_lines":[{"line_number":103,"context_line":"   ``oslo.middleware``."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"In this case the header has already said that the value is a"},{"line_number":106,"context_line":"request ID: the use of \"req\" in the value to indicate \"request\" is"},{"line_number":107,"context_line":"redundant. Additionally since the value is a UUID there is no need"},{"line_number":108,"context_line":"to put it in a namespace."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a061dce_efe16a2b","line":106,"range":{"start_line":106,"start_character":24,"end_line":106,"end_character":27},"in_reply_to":"9a061dce_db4c55ca","updated":"2016-04-07 16:08:14.000000000","message":"This currently has an impact on logging because of how it\u0027s used in oslo.context.\n\nNot all places where this data is going to exist will it exist with the header name.\n\nI think before moving forward on something like this we should be make sure we understand the real world downstream impacts.","commit_id":"8126416f823a7cefaefba261a1cf29aac88fb859"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"4304422dcc4d2de2bee7728803f2d7f50acc2336","unresolved":false,"context_lines":[{"line_number":103,"context_line":"   ``oslo.middleware``."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"In this case the header has already said that the value is a"},{"line_number":106,"context_line":"request ID: the use of \"req\" in the value to indicate \"request\" is"},{"line_number":107,"context_line":"redundant. Additionally since the value is a UUID there is no need"},{"line_number":108,"context_line":"to put it in a namespace."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a061dce_76b50930","line":106,"in_reply_to":"9a061dce_efe16a2b","updated":"2016-04-08 10:19:53.000000000","message":"There\u0027s a bit of conflict when writing these guidelines. It\u0027s useful to use a concrete example to demonstrate where something is being used in a way that is less than ideal. Doing so should not mean that we are going to change that instance of the bad behavior.\n\nThis guideline does not suggest that we go back and change the value of the request-id. It merely says that the way in which request id was done is not optimal so let\u0027s learn from that and do things differently going forward.\n\nThis kind of reaction has become a bit of a trend, so it is clear I need to change something about the way I\u0027m writing the guidelines so that the demonstration of error is not taken as a call to change the past. If guidelines are consistently taken that way then there won\u0027t be any improvement: the amount of stop energy to overcome to indicate a path out of the bad will be too long.\n\nSo: two questions:\n\n* What do I need to do here, in this guideline, to indicate that it is not proposing that oslo request id be changed?\n* What do I need to do, in guidelines in general, to make it clear when concrete examples are being used for illustrative purposes, not prescriptive?","commit_id":"8126416f823a7cefaefba261a1cf29aac88fb859"}]}