)]}'
{"specs/ocata/approved/extra-specs-image-meta-conflicts.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"dff12a8014a675f4b1eba2940489e6e239389b7b","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  require   prefer/isolate  exception"},{"line_number":62,"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\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":63,"context_line":""},{"line_number":64,"context_line":"We have two rather different behaviors for NUMA related properties.  If first"},{"line_number":65,"context_line":"case we prefer stricter non-default value, but in second case we prefer softer"},{"line_number":66,"context_line":"default value."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The only phrase in spec for these paricular policies [2]_ regarding handling of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a95cdbc_1359e4fe","line":65,"range":{"start_line":64,"start_character":69,"end_line":65,"end_character":4},"updated":"2016-10-05 15:49:05.000000000","message":"\"In the first case\" ?","commit_id":"dd35f8024f0f3cba06a60bd202e7fee6e98a09fb"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"b82c16fa259458fb72a8398d53aaaf3d143a5c11","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  require   prefer/isolate  exception"},{"line_number":62,"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\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":63,"context_line":""},{"line_number":64,"context_line":"We have two rather different behaviors for NUMA related properties.  If first"},{"line_number":65,"context_line":"case we prefer stricter non-default value, but in second case we prefer softer"},{"line_number":66,"context_line":"default value."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The only phrase in spec for these paricular policies [2]_ regarding handling of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a95cdbc_fd6ee32d","line":65,"range":{"start_line":64,"start_character":69,"end_line":65,"end_character":4},"in_reply_to":"1a95cdbc_1359e4fe","updated":"2016-10-06 10:35:12.000000000","message":"Copy-paste typo from bug report. Done.","commit_id":"dd35f8024f0f3cba06a60bd202e7fee6e98a09fb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"dff12a8014a675f4b1eba2940489e6e239389b7b","unresolved":false,"context_lines":[{"line_number":94,"context_line":"warning users about this new behavior."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"In the second stage, the warning will be replaced with exceptions. This will"},{"line_number":97,"context_line":"ensure the user can no longer specify conflicting options without error."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"Alternatives"},{"line_number":100,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a95cdbc_33450017","line":97,"updated":"2016-10-05 15:49:05.000000000","message":"Did someone suggest doing this as two phases? I\u0027m not really sure why we wouldn\u0027t go straight to throwing errors for impossible cases. The longer we let people specify the wrong thing without failing, the more entrenched that wrong behavior will be.\n\nI get that breaking people suddenly is a thing, but these are already wrong, right? Why not just shortcut straight to phase 2?","commit_id":"dd35f8024f0f3cba06a60bd202e7fee6e98a09fb"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"b82c16fa259458fb72a8398d53aaaf3d143a5c11","unresolved":false,"context_lines":[{"line_number":94,"context_line":"warning users about this new behavior."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"In the second stage, the warning will be replaced with exceptions. This will"},{"line_number":97,"context_line":"ensure the user can no longer specify conflicting options without error."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"Alternatives"},{"line_number":100,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a95cdbc_609cec69","line":97,"in_reply_to":"1a95cdbc_33450017","updated":"2016-10-06 10:35:12.000000000","message":"\u003e Did someone suggest doing this as two phases? I\u0027m not really sure why we wouldn\u0027t go straight to throwing errors for impossible cases. The longer we let people specify the wrong thing without failing, the more entrenched that wrong behavior will be.\n\nI was adopting the same policy we\u0027ve used in the centralize-config-options bps. For that spec, we found a lot of the IntOpt configuration option didn\u0027t limit values correctly, allowing negative values which would either (a) break something or (b) actually work but not make semantic sense. We were able to fix the former in-place (since it never worked, it wouldn\u0027t hurt anyone), but for the latter we decided to log for one cycle in case folks were doing daft but technically valid things. \n\n \u003e I get that breaking people suddenly is a thing, but these are already wrong, right? Why not just shortcut straight to phase 2?\n\nYeah, the problem is that we don\u0027t have a clear definition of what \"wrong\" is (which whole point of this spec, heh). Take the handling CPU policy vs. CPU thread policy above for example. For the former, we prefer non-stricter options. For the latter, however, we prefer the less stricter options. Depending on your perspective, either one of these could be the correct approach. What I\u0027m seeking to do is to define \"wrong\" as \"image metadata !\u003d \u003cdefault\u003e AND flavor extra spec \u003d\u003d \u003canything\u003e\", but this doesn\u0027t necessarily tie in with how folks are doing this right now. This mismatch could cause broken deployments, which is something we certainly want to avoid, right?","commit_id":"dd35f8024f0f3cba06a60bd202e7fee6e98a09fb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"dff12a8014a675f4b1eba2940489e6e239389b7b","unresolved":false,"context_lines":[{"line_number":109,"context_line":"REST API impact"},{"line_number":110,"context_line":"---------------"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"None."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Security impact"},{"line_number":115,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a95cdbc_b3683089","line":112,"updated":"2016-10-05 15:49:05.000000000","message":"No REST API impact for the first phase I guess...","commit_id":"dd35f8024f0f3cba06a60bd202e7fee6e98a09fb"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"b82c16fa259458fb72a8398d53aaaf3d143a5c11","unresolved":false,"context_lines":[{"line_number":109,"context_line":"REST API impact"},{"line_number":110,"context_line":"---------------"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"None."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Security impact"},{"line_number":115,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a95cdbc_60d86c1e","line":112,"in_reply_to":"1a95cdbc_b3683089","updated":"2016-10-06 10:35:12.000000000","message":"Doesn\u0027t this section deal with the actual API itself? There might be a few extra exceptions raised for people with ill-defined image/flavor specs, but the functionality of the API itself (how we report exceptions, the response bodies for each endpoint etc.) won\u0027t change","commit_id":"dd35f8024f0f3cba06a60bd202e7fee6e98a09fb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"dff12a8014a675f4b1eba2940489e6e239389b7b","unresolved":false,"context_lines":[{"line_number":157,"context_line":""},{"line_number":158,"context_line":"#. Add warnings to all locations where image metadata and flavor extra specs"},{"line_number":159,"context_line":"   are compared and conflicts arise"},{"line_number":160,"context_line":"#. Update documentation to reflect this requirement"},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"Then, in the following cycle."},{"line_number":163,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a95cdbc_b31670ef","line":160,"updated":"2016-10-05 15:49:05.000000000","message":"So, as proposed, this spec in Ocata is purely \"add some warning logs and update the docs\" ?\n\nIf so, I don\u0027t really feel like we need a spec for that -- bugs would be more than sufficient. However, as I said above, I think we should go straight for phase 2, personally.","commit_id":"dd35f8024f0f3cba06a60bd202e7fee6e98a09fb"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"b82c16fa259458fb72a8398d53aaaf3d143a5c11","unresolved":false,"context_lines":[{"line_number":157,"context_line":""},{"line_number":158,"context_line":"#. Add warnings to all locations where image metadata and flavor extra specs"},{"line_number":159,"context_line":"   are compared and conflicts arise"},{"line_number":160,"context_line":"#. Update documentation to reflect this requirement"},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"Then, in the following cycle."},{"line_number":163,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a95cdbc_802c9803","line":160,"in_reply_to":"1a95cdbc_b31670ef","updated":"2016-10-06 10:35:12.000000000","message":"I\u0027m happy to go straight to phase 2 *if* you\u0027re happy that we\u0027re not going to upset too many people :) See above.\n\nIf we don\u0027t go to phase two, how should I track this work? Specless blueprint?","commit_id":"dd35f8024f0f3cba06a60bd202e7fee6e98a09fb"},{"author":{"_account_id":9569,"name":"Sergey Nikitin","email":"nikitinserv@gmail.com","username":"snikitin"},"change_message_id":"311cc47ed4b78380d93485d7cd891b0a6483457e","unresolved":false,"context_lines":[{"line_number":8,"context_line":"Consistent extra spec-image metadata conflict handling"},{"line_number":9,"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\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":10,"context_line":""},{"line_number":11,"context_line":"Include the URL of your launchpad blueprint:"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"https://blueprints.launchpad.net/nova/+spec/extra-specs-image-meta-conflicts"},{"line_number":14,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa6399be_e7050846","line":11,"updated":"2016-10-14 15:30:42.000000000","message":"Forgot to delete :)","commit_id":"3d8412eb153b4c6adba70a5ae32b051432dd51fc"}],"specs/pike/approved/extra-specs-image-meta-conflicts.rst":[{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"0fd0162f07477ec1dbb33ccdbe4296f3a75b0fbd","unresolved":false,"context_lines":[{"line_number":79,"context_line":"* As a user, I want to know what will happen if a conflict occurs between image"},{"line_number":80,"context_line":"  metadata and flavor extra specs"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"* As an administrator, I want to prevent users overriding important image"},{"line_number":83,"context_line":"  metadata"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"* As a developer, I want a clearly defined pattern for handling image"},{"line_number":86,"context_line":"  metadata/flavor extra spec conflicts"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3a1ff146_5a5bba54","line":83,"range":{"start_line":82,"start_character":68,"end_line":83,"end_character":10},"updated":"2017-03-14 18:32:25.000000000","message":"flavor extra specs?","commit_id":"8e02c4f49253c9ac8e1d442ad5996447a958263f"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"2b7be3906016dd6a4fdc9cd7cae7f63f6457fb7b","unresolved":false,"context_lines":[{"line_number":23,"context_line":""},{"line_number":24,"context_line":"* CPU allocation policy"},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"  Image: ``hw:cpu_thread_policy``"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"  Flavor: ``hw:cpu_thread_policy``"},{"line_number":29,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"dfeb2761_ce864214","line":26,"updated":"2017-04-04 16:42:31.000000000","message":"You mean ``hw:cpu_policy``? I feel like this is a mistaken copy-paste from somewhere (possibly lines 34 and/or 36).","commit_id":"6d03ed535a199be92accf3c835e158c1bb2801a8"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"2b7be3906016dd6a4fdc9cd7cae7f63f6457fb7b","unresolved":false,"context_lines":[{"line_number":25,"context_line":""},{"line_number":26,"context_line":"  Image: ``hw:cpu_thread_policy``"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"  Flavor: ``hw:cpu_thread_policy``"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"  Values: ``shared`` (softer, default), ``dedicated`` (stricter)"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"dfeb2761_ae7f7e13","line":28,"updated":"2017-04-04 16:42:31.000000000","message":"Ditto.","commit_id":"6d03ed535a199be92accf3c835e158c1bb2801a8"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"2b7be3906016dd6a4fdc9cd7cae7f63f6457fb7b","unresolved":false,"context_lines":[{"line_number":134,"context_line":"Other deployer impact"},{"line_number":135,"context_line":"---------------------"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"Deployers may see new warnings when deploying images with some metadata set"},{"line_number":138,"context_line":"against flavors with competing extra specs. However, actual behavior of"},{"line_number":139,"context_line":"existing options will not change."},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"dfeb2761_2ec92e25","line":137,"updated":"2017-04-04 16:42:31.000000000","message":"When you deploy an image there\u0027s no flavor associated with it, right? The checks you\u0027re talking about would happen at instance boot time, when an association between an image and a flavor has been made (through the instance itself). How will the deployers see the warnings then? Maybe Dan is right, just go straight to breaking people.\n\nSpeculating out loud: perhaps do it in a new API version, if that\u0027s feasible, to lessen the pain? The change would imply that a server boot request would return a 400 where it previously returned 202, right?","commit_id":"6d03ed535a199be92accf3c835e158c1bb2801a8"}]}
