)]}'
{"specs/logging-message-ids.rst":[{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"7d92df424b41db2644fbe0322cf68b7b98419125","unresolved":false,"context_lines":[{"line_number":146,"context_line":"   added to the call? Make oslo.log derive the name portion of the ID"},{"line_number":147,"context_line":"   based on where the log call is made?"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"2. We may not want to start publishing a given troubleshooting guide"},{"line_number":150,"context_line":"   until there is a critical mass of useful information written for"},{"line_number":151,"context_line":"   it. How do we decide when to start publishing? When should new"},{"line_number":152,"context_line":"   troubleshooting guides be added to the list of published guides?"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ff73747_2a901143","line":149,"updated":"2017-04-26 14:13:29.000000000","message":"+1","commit_id":"d9ed138f8286a9e74d3d45118549711b5e157420"},{"author":{"_account_id":11303,"name":"Markus Zoeller (markus_z)","email":"mzoeller@linux.vnet.ibm.com","username":"mzoeller"},"change_message_id":"f190e0f2e5234f5c871111689eb426278ecc8f5c","unresolved":false,"context_lines":[{"line_number":68,"context_line":"them. Operators should still be able to understand what OpenStack is"},{"line_number":69,"context_line":"doing by reading the logs, without the troubleshooting guides."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Each situation ID is a combination of the project name and a 6 digit"},{"line_number":72,"context_line":"number (000000-999999).  Because the IDs are tied to documentation in"},{"line_number":73,"context_line":"a git repository, all of the services delivered from that repository"},{"line_number":74,"context_line":"should use IDs allocated from the same range (i.e., all of the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_5e487a85","line":71,"range":{"start_line":71,"start_character":42,"end_line":71,"end_character":54},"updated":"2017-04-28 10:01:39.000000000","message":"Does it make sense to care about a fixed \"column-width\" for the message ID? I\u0027m wondering how this would look like in a setup where 10+ projects are emitting messages, each project with a different length of the name. Take \"ceilometer\" and \"nova\" for example. \n\n*If* we care about a fixed column-width, then a possible aggregation log would look like:\n\n    [req-\u003cuuid\u003e] nova-123456 \"this happened\"\n    [req-\u003cuuid\u003e] ceilometer-789123 \"that happened\"\n\nIf we do left padding:\n\n    [req-\u003cuuid\u003e]       nova-123456 \"this happened\"\n    [req-\u003cuuid\u003e] ceilometer-789123 \"that happened\"\n\nIf we abbreviate:\n\n    [req-\u003cuuid\u003e] nova-123456 \"this happened\"\n    [req-\u003cuuid\u003e] ceil-789123 \"that happened\"\n\ncdent also pointed out the issue when pieces of a project become a new project. Nova for example, is working on the \"placement\" service, which is part of Nova, but is designed to be carved out into a new project. If the project name is used in the message, all of the current nova placement message code will look like:\n\n    nova-123456 \"placement is happening\"\n    nova-456789 \"placement found a good place\"\n    nova-789123 \"placement has happened\"\n    \nIf the rule from line 71 is applied, that needs to be changed when the code gets moved into the new project \"placement\":\n\n    placement-123456 \"placement is happening\"\n    placement-456789 \"placement found a good place\"\n    placement-789123 \"placement has happened\"\n\nThe semantic of those messages are the very same, but the IDs have changed. (Potential) monitoring software which listens for the IDs won\u0027t work until the monitoring logic gets updated.\n\nI assume the reason for adding the project name to the ID is part of assigning a range for the projects to avoid cross-project collisions? If that\u0027s the case, we might simply want to increase the range of allowed values and drop the project name as a mandatory part of it. Which means, instead of having:\n\n    nova-123456 \"placement is happening\"\n    nova-456789 \"placement found a good place\"\n    nova-789123 \"placement has happened\"\n\nwe could have:\n\n    AB8596LI \"placement is happening\"\n    XKLO34SD \"placement found a good place\"\n    15KLRS4F \"placement has happened\"\n\nThe benefit would be that we don\u0027t have to care about when code moves to new projects (which is a very good thing to keep the complexity low IMHO). \n\nAs suggested in line 117, a big enough range gives a very low probability of (cross-project) message ID collisions:\n\n                                      Unique IDs             Unique IDs\nIdea  Format                          per project         OpenStack wide\n------------------------------------------------------------------------\n1     \u003cproject-name\u003e-[000000-999999]              10^6  #projects * 10^6\n2     [000000-ZZZZZZ]                 36^6 / #projects              36^6\n3     [00000000-ZZZZZZZZ]             36^8 / #projects              36^8\n\n#projects \u003d\u003d ~ 1500 (at the moment)\n\nIdea 2 and 3 have a very low probability that an ID gets used a second time.\nIt\u0027s pretty low IMO, and even if this get\u0027s noticed the cost of fixing it is\nlower than trying to prevent it in the first place IMO.","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"05a466b26642d9e634f7286efc1ca4641524335d","unresolved":false,"context_lines":[{"line_number":68,"context_line":"them. Operators should still be able to understand what OpenStack is"},{"line_number":69,"context_line":"doing by reading the logs, without the troubleshooting guides."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Each situation ID is a combination of the project name and a 6 digit"},{"line_number":72,"context_line":"number (000000-999999).  Because the IDs are tied to documentation in"},{"line_number":73,"context_line":"a git repository, all of the services delivered from that repository"},{"line_number":74,"context_line":"should use IDs allocated from the same range (i.e., all of the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_c5eb9275","line":71,"range":{"start_line":71,"start_character":42,"end_line":71,"end_character":54},"in_reply_to":"5ff73747_5e487a85","updated":"2017-04-28 12:44:50.000000000","message":"Lots of aspects of our logs don\u0027t fit into neat columns. I was not concerned with forcing IDs to fit into columns either. If we want to do that, I think dropping the prefix and just logging the number is probably the way to go.\n\nThe problem with how to deal with IDs when a project splits across repositories is definitely there. In my mind, it\u0027s another example of why maintaining these ID values is going to be far more expensive, long term, than we want to deal with. Every time we introduce a new piece of complexity into the process of ensuring good technical decisions are made, we make it harder to eliminate technical debt and otherwise improve the overall health of the system.","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":11303,"name":"Markus Zoeller (markus_z)","email":"mzoeller@linux.vnet.ibm.com","username":"mzoeller"},"change_message_id":"1cd63a12717ca2f243f51ed4fa93b080618cf40d","unresolved":false,"context_lines":[{"line_number":114,"context_line":"documentation should also update all of the related logging calls to"},{"line_number":115,"context_line":"pass the situation_id. Because the IDs come from filenames, we can use"},{"line_number":116,"context_line":"merge conflicts to help us catch cases of reusing the same ID"},{"line_number":117,"context_line":"incorrectly."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Once allocated, a situation ID is not changed. If the text of a log"},{"line_number":120,"context_line":"message associated with a situation ID changes, the documentation for"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_243f0188","line":117,"updated":"2017-04-27 14:01:03.000000000","message":"I\u0027m wondering how the allocation process will look like in our daily business. \nI understand that there is a range of of valid IDs (line 72) and I understand that each project *can* do a partitioning on their own (lines 125-130). I used partitioning rules within my company 4 years ago, and they worked somewhat fine (but we used upper case letters too, which means we had a much bigger range with that). \nMy concern is, that I only really know if I\u0027m using a unique ID  in my (to be pushed) change *after* I scanned the master code + the open reviews (which also try to add situation or message IDs). It wouldn\u0027t be fun to push new patchsets because another change (with the same ID) merged before mine.\nPartitioning rules would mitigate that issue, but then we might not have a big enough range (with the range suggested in line 72). \nIn line 226 you talk about using UUIDs as an alternative and I think generating an ID (in whatever format) might be the best way to avoid (or reduce the probability) of merge conflicts. I very much love the hashing idea of \"reno\" to ensure uniqueness of release note files and I thought we might want to apply the idea here too.\n\nLong story short, generating locally an ID which also allows upper case letters (regex: [A-Z0-9]{6}) might be a good tradeoff between mnemonic (enough) and unique (enough). My potential workflow could be:\n\n    $ cd /nova\n    $ tox -e msgid\n    generated unique situation ID: nova-1ZD49A\n\nAnd then use this ID in my code. That would mean we don\u0027t have partitioning rules which we need to check by hacking rules or reviews, which would make things easier IMO.","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":11303,"name":"Markus Zoeller (markus_z)","email":"mzoeller@linux.vnet.ibm.com","username":"mzoeller"},"change_message_id":"a29dcecb14968d2b4406d734da96d1b5e466ec84","unresolved":false,"context_lines":[{"line_number":114,"context_line":"documentation should also update all of the related logging calls to"},{"line_number":115,"context_line":"pass the situation_id. Because the IDs come from filenames, we can use"},{"line_number":116,"context_line":"merge conflicts to help us catch cases of reusing the same ID"},{"line_number":117,"context_line":"incorrectly."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Once allocated, a situation ID is not changed. If the text of a log"},{"line_number":120,"context_line":"message associated with a situation ID changes, the documentation for"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_ddd15025","line":117,"in_reply_to":"5ff73747_1af1fe01","updated":"2017-04-27 14:29:34.000000000","message":"Yes, the collision issue can become frustrating very fast. If it\u0027s solved by UUID4 with less bits, I\u0027m OK with it. :)","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"b8f734a50e47276a0171d4c4801ae176ccc5db75","unresolved":false,"context_lines":[{"line_number":114,"context_line":"documentation should also update all of the related logging calls to"},{"line_number":115,"context_line":"pass the situation_id. Because the IDs come from filenames, we can use"},{"line_number":116,"context_line":"merge conflicts to help us catch cases of reusing the same ID"},{"line_number":117,"context_line":"incorrectly."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Once allocated, a situation ID is not changed. If the text of a log"},{"line_number":120,"context_line":"message associated with a situation ID changes, the documentation for"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_1af1fe01","line":117,"in_reply_to":"5ff73747_243f0188","updated":"2017-04-27 14:11:23.000000000","message":"This is an interesting alternative, and does avoid the collision issue. It may also address some of the reviewer issues, since without a partitioned range the only thing a reviewer needs to check is the uniqueness and we can automate that. Reno uses a random number, and I guess we could do something like that here (that\u0027s essentially what a UUID4 is, we just wouldn\u0027t need so many bits).","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":11303,"name":"Markus Zoeller (markus_z)","email":"mzoeller@linux.vnet.ibm.com","username":"mzoeller"},"change_message_id":"1cd63a12717ca2f243f51ed4fa93b080618cf40d","unresolved":false,"context_lines":[{"line_number":168,"context_line":"   attempt to invert that situation."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"2. We could, once and for all, declare that this is not a feature we"},{"line_number":171,"context_line":"   are going to add to OpenStack."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"3. We could adopt this proposal, but include a unique ID for every"},{"line_number":174,"context_line":"   message instead of collecting related messages together with the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_67be2bd6","line":171,"updated":"2017-04-27 14:01:03.000000000","message":"Back when I did bug triage, I always wanted to have such IDs. They would have made my life a lot easier. Also the pattern matching in elastic search could be easier with message IDs. Which means I\u0027m very pro adding message IDs.","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":11303,"name":"Markus Zoeller (markus_z)","email":"mzoeller@linux.vnet.ibm.com","username":"mzoeller"},"change_message_id":"a29dcecb14968d2b4406d734da96d1b5e466ec84","unresolved":false,"context_lines":[{"line_number":168,"context_line":"   attempt to invert that situation."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"2. We could, once and for all, declare that this is not a feature we"},{"line_number":171,"context_line":"   are going to add to OpenStack."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"3. We could adopt this proposal, but include a unique ID for every"},{"line_number":174,"context_line":"   message instead of collecting related messages together with the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_fa489287","line":171,"in_reply_to":"5ff73747_1a269e69","updated":"2017-04-27 14:29:34.000000000","message":"I wasn\u0027t (and still aren\u0027t) very profound in the (nova) code base. When doing a bug triage, I did google around and look in the ML if anyone has written about this or that message, but without a unique handle I had difficulties to be sure that they talked about the very same thing. Also, a google search for a messages with placeholders and line breaks, or dynamically generated message content, was sometimes cumbersome. A search for a unique ID is so much simpler.","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"b8f734a50e47276a0171d4c4801ae176ccc5db75","unresolved":false,"context_lines":[{"line_number":168,"context_line":"   attempt to invert that situation."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"2. We could, once and for all, declare that this is not a feature we"},{"line_number":171,"context_line":"   are going to add to OpenStack."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"3. We could adopt this proposal, but include a unique ID for every"},{"line_number":174,"context_line":"   message instead of collecting related messages together with the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_1a269e69","line":171,"in_reply_to":"5ff73747_67be2bd6","updated":"2017-04-27 14:11:23.000000000","message":"Can you elaborate on how they help with debugging, aside from finding the line in the code where a log message is produced?","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":11303,"name":"Markus Zoeller (markus_z)","email":"mzoeller@linux.vnet.ibm.com","username":"mzoeller"},"change_message_id":"1cd63a12717ca2f243f51ed4fa93b080618cf40d","unresolved":false,"context_lines":[{"line_number":171,"context_line":"   are going to add to OpenStack."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"3. We could adopt this proposal, but include a unique ID for every"},{"line_number":174,"context_line":"   message instead of collecting related messages together with the"},{"line_number":175,"context_line":"   same ID. Validating the uniqueness across logging calls would be a"},{"line_number":176,"context_line":"   bit more complex, but could be done. It\u0027s not clear that it\u0027s worth"},{"line_number":177,"context_line":"   the effort."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_47968f41","line":174,"updated":"2017-04-27 14:01:03.000000000","message":"I haven\u0027t yet read your blog post about this topic, so I don\u0027t yet fully understand under which conditions I would have \"related messages\" which are allowed to share the same situation ID. Right now I would tend to have unique IDs for every message.","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"b8f734a50e47276a0171d4c4801ae176ccc5db75","unresolved":false,"context_lines":[{"line_number":171,"context_line":"   are going to add to OpenStack."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"3. We could adopt this proposal, but include a unique ID for every"},{"line_number":174,"context_line":"   message instead of collecting related messages together with the"},{"line_number":175,"context_line":"   same ID. Validating the uniqueness across logging calls would be a"},{"line_number":176,"context_line":"   bit more complex, but could be done. It\u0027s not clear that it\u0027s worth"},{"line_number":177,"context_line":"   the effort."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_fab892e5","line":174,"in_reply_to":"5ff73747_47968f41","updated":"2017-04-27 14:11:23.000000000","message":"The blog post doesn\u0027t get into that. I was thinking that, within a given method there may be INFO and WARNING messages, and those might be related. I don\u0027t know how common that case will really be, though. I\u0027m trying to be flexible, since I don\u0027t think it costs anything in this case.","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":11303,"name":"Markus Zoeller (markus_z)","email":"mzoeller@linux.vnet.ibm.com","username":"mzoeller"},"change_message_id":"1cd63a12717ca2f243f51ed4fa93b080618cf40d","unresolved":false,"context_lines":[{"line_number":176,"context_line":"   bit more complex, but could be done. It\u0027s not clear that it\u0027s worth"},{"line_number":177,"context_line":"   the effort."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"4. We could place the message documentation in a centralized guide,"},{"line_number":180,"context_line":"   instead of placing each section in the same repository as the"},{"line_number":181,"context_line":"   application to which it refers. Setting message IDs in the central"},{"line_number":182,"context_line":"   guide would make validation more complex, since the validator would"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_e7fb5b76","line":179,"updated":"2017-04-27 14:01:03.000000000","message":"The guide which is closest to the needs described in this spec might be the \"configuration reference\" guide. The docs are in the projects (as docstrings in the code) but the overall \"framework document\" is in the manuals repository. Maybe that can be applied to this situation here too.","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"b8f734a50e47276a0171d4c4801ae176ccc5db75","unresolved":false,"context_lines":[{"line_number":176,"context_line":"   bit more complex, but could be done. It\u0027s not clear that it\u0027s worth"},{"line_number":177,"context_line":"   the effort."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"4. We could place the message documentation in a centralized guide,"},{"line_number":180,"context_line":"   instead of placing each section in the same repository as the"},{"line_number":181,"context_line":"   application to which it refers. Setting message IDs in the central"},{"line_number":182,"context_line":"   guide would make validation more complex, since the validator would"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_7ac4825f","line":179,"in_reply_to":"5ff73747_e7fb5b76","updated":"2017-04-27 14:11:23.000000000","message":"I\u0027ve included this alternative for completeness, but I can\u0027t really imagine any scenario in which we could do this successfully with a central registry.","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":11303,"name":"Markus Zoeller (markus_z)","email":"mzoeller@linux.vnet.ibm.com","username":"mzoeller"},"change_message_id":"1cd63a12717ca2f243f51ed4fa93b080618cf40d","unresolved":false,"context_lines":[{"line_number":190,"context_line":"5. We could place the troubleshooting guide for an application, or set"},{"line_number":191,"context_line":"   of applications, in its own repository. This solves the ownership"},{"line_number":192,"context_line":"   question, but has the same validation-related drawbacks as creating"},{"line_number":193,"context_line":"   a centralized guide.  comment"},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"6. We could place the situation ID at the start of the logging output"},{"line_number":196,"context_line":"   and replace missing ID values with \"-\", as we do for other key"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_27338364","line":193,"range":{"start_line":193,"start_character":25,"end_line":193,"end_character":32},"updated":"2017-04-27 14:01:03.000000000","message":"nit: there\u0027s a superfluous word","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":11303,"name":"Markus Zoeller (markus_z)","email":"mzoeller@linux.vnet.ibm.com","username":"mzoeller"},"change_message_id":"1cd63a12717ca2f243f51ed4fa93b080618cf40d","unresolved":false,"context_lines":[{"line_number":206,"context_line":"   for a future enhancement, when we have enough situation IDs"},{"line_number":207,"context_line":"   documented to make it useful."},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"8. We could use hexadecimal instead of decimal codes to extend the"},{"line_number":210,"context_line":"   ranges. Starting with decimal allows us to extend the range later"},{"line_number":211,"context_line":"   if we need to go beyond 1,000,000 codes for any given application."},{"line_number":212,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_4780cfc0","line":209,"updated":"2017-04-27 14:01:03.000000000","message":"As described in line 117, maybe we want to go for the range [A-Z0-9]{6}","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"1e57cac10918aebb5d103473bea305244259ce99","unresolved":false,"context_lines":[{"line_number":231,"context_line":"    contributor to run a tool to produce the value, which makes it"},{"line_number":232,"context_line":"    slightly more difficult to add a message ID. UUIDs are also harder"},{"line_number":233,"context_line":"    to remember and relay in non-text mediums, which may make them"},{"line_number":234,"context_line":"    less useful as mnemonics."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"12. The Fault Genes team has a tool to scrape code for exceptions and"},{"line_number":237,"context_line":"    build a searchable database of error messages from"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_0e9d3c09","line":234,"updated":"2017-04-27 15:51:47.000000000","message":"If the primary purpose of the id is to allow humans to look up the id, grep with the id, speak about the id, take the id for a ride in a mail message, etc then a UUID presents challenges for that human.\n\nHowever, if the first step anyone is going to when getting the id is enter it into the troubleshoot.openstack.org then a uuid isn\u0027t a big deal and has great benefits in terms of persistence and uniqueness.\n\nThe PROJECT-000099 version suffers from a common flaw (it contains real world info in the id): What happens when that situation moves to a different project, or the project decomposes into small pieces?","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"14dee68709eae387b1ccff9ce9e65bcd099749bb","unresolved":false,"context_lines":[{"line_number":231,"context_line":"    contributor to run a tool to produce the value, which makes it"},{"line_number":232,"context_line":"    slightly more difficult to add a message ID. UUIDs are also harder"},{"line_number":233,"context_line":"    to remember and relay in non-text mediums, which may make them"},{"line_number":234,"context_line":"    less useful as mnemonics."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"12. The Fault Genes team has a tool to scrape code for exceptions and"},{"line_number":237,"context_line":"    build a searchable database of error messages from"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_2696d84d","line":234,"in_reply_to":"5ff73747_0e9d3c09","updated":"2017-04-27 19:34:26.000000000","message":"Yeah, UUIDs are less likely to produce collisions when created but are going to fail the \"read it over the phone to the support hotline\" and \"remember it from the last time you saw it\" tests pretty badly.\n\nI hadn\u0027t considered the case of an ID moving to another project. I suppose if a project decomposes into different repos (such as might happen with the scheduler at some point), the IDs could stay the same except for the prefix? The docs could move with the code, too. I\u0027m not sure what would happen to the IDs in the old repo. That\u0027s definitely a complication we\u0027d have to consider.","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":11303,"name":"Markus Zoeller (markus_z)","email":"mzoeller@linux.vnet.ibm.com","username":"mzoeller"},"change_message_id":"f190e0f2e5234f5c871111689eb426278ecc8f5c","unresolved":false,"context_lines":[{"line_number":231,"context_line":"    contributor to run a tool to produce the value, which makes it"},{"line_number":232,"context_line":"    slightly more difficult to add a message ID. UUIDs are also harder"},{"line_number":233,"context_line":"    to remember and relay in non-text mediums, which may make them"},{"line_number":234,"context_line":"    less useful as mnemonics."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"12. The Fault Genes team has a tool to scrape code for exceptions and"},{"line_number":237,"context_line":"    build a searchable database of error messages from"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_2bcfae56","line":234,"in_reply_to":"5ff73747_2696d84d","updated":"2017-04-28 10:01:39.000000000","message":"cdent has a very valid point about a \"situation\" overlapping projects. For example, the complicated tasks in Nova (the tasks you want to know more about), need interaction with Neutron and Cinder (at least). Coming from the perspective of a developer who wants to introduce a message with an ID, I\u0027m already afraid of the discussions if this is (or isn\u0027t) a situation which needs the same ID as defined in Cinder/Neutron. Which makes me argue against having a \"situation ID\" which is used multiple times. \nI\u0027m also not sure if there will ever be a common understanding of a \"situation\". I have no operators experience, I simply would assume that operators do the pattern matching in their brains based on experience, like \"there are the message IDs \u0027X8F123\u0027 and \u0027AB1258\u0027 and \u0027GH9876\u0027, that mean\u0027s I\u0027m in situation XY\".","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"},{"author":{"_account_id":11303,"name":"Markus Zoeller (markus_z)","email":"mzoeller@linux.vnet.ibm.com","username":"mzoeller"},"change_message_id":"1cd63a12717ca2f243f51ed4fa93b080618cf40d","unresolved":false,"context_lines":[{"line_number":256,"context_line":"    to the exception class will make sense in the long run, although"},{"line_number":257,"context_line":"    it doesn\u0027t address the standalone logging messages."},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"14. We could call \"situation IDs\" \"message IDs\" instead. The alternate"},{"line_number":260,"context_line":"    name was proposed because the values are not unique to the"},{"line_number":261,"context_line":"    message, but if it causes confusion that distinction may not be"},{"line_number":262,"context_line":"    worth making."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ff73747_67c06be2","line":259,"updated":"2017-04-27 14:01:03.000000000","message":"When I started the spec and you explained that the ID has the name \"situation ID\" I was confused, until I read that the ID gets re-used over multiple messages. If we go for re-used IDs in different messages, then \"situation ID\" is better then \"message ID\".","commit_id":"53a2d8076dd2b6650fa27bacca7d9422f5e2622a"}]}