)]}'
{"specs/grenade/api-uptime.rst":[{"author":{"_account_id":9152,"name":"Castulo J. Martinez","email":"castulo.martinez@intel.com","username":"cas"},"change_message_id":"32464727374c7aeafffd9b3430da36240a08cefa","unresolved":false,"context_lines":[{"line_number":23,"context_line":""},{"line_number":24,"context_line":"* Introduce two new phases into the Grenade basic flow"},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"  * Start API uptime validtion. "},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"    * This will allow one (or more) tests to be run over"},{"line_number":29,"context_line":"      time while an upgrade is in process"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a3905b3_5f9d5164","line":26,"range":{"start_line":26,"start_character":21,"end_line":26,"end_character":30},"updated":"2017-01-19 18:24:47.000000000","message":"typo","commit_id":"cb79afcc25d5a0f55e8fe2debab3a12b7c95a44c"},{"author":{"_account_id":9152,"name":"Castulo J. Martinez","email":"castulo.martinez@intel.com","username":"cas"},"change_message_id":"32464727374c7aeafffd9b3430da36240a08cefa","unresolved":false,"context_lines":[{"line_number":64,"context_line":"----------"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"Target Milestone for completion:"},{"line_number":67,"context_line":"  Ocata-2"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"Work Items"},{"line_number":70,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a3905b3_dfedc18c","line":67,"range":{"start_line":67,"start_character":2,"end_line":67,"end_character":9},"updated":"2017-01-19 18:24:47.000000000","message":"Didn\u0027t you mean Pike-2?","commit_id":"cb79afcc25d5a0f55e8fe2debab3a12b7c95a44c"},{"author":{"_account_id":17716,"name":"Luz Cazares","email":"luz.cazares@intel.com","username":"luzcazares"},"change_message_id":"9e696ffbdacd7217920c9e6b73bb61a0f3c14d84","unresolved":false,"context_lines":[{"line_number":78,"context_line":"Dependencies"},{"line_number":79,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"References"},{"line_number":82,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":83,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a3905b3_22006a34","line":81,"range":{"start_line":81,"start_character":1,"end_line":81,"end_character":10},"updated":"2017-01-19 18:45:30.000000000","message":"Probably add project tags for zero-downtime: https://governance.openstack.org/tc/reference/tags/assert_supports-zero-downtime-upgrade.html","commit_id":"cb79afcc25d5a0f55e8fe2debab3a12b7c95a44c"},{"author":{"_account_id":2750,"name":"Sean Dague","email":"sean@dague.net","username":"sdague"},"change_message_id":"67d1cbd1548da5f401ca395ddf2500c5e4d78632","unresolved":false,"context_lines":[{"line_number":34,"context_line":"      mentioned above."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"* Introduce new reporting metrics to prove the api was, indeed,"},{"line_number":37,"context_line":"  available and functional during the upgrade."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":""},{"line_number":40,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a461143_786246da","line":37,"updated":"2017-01-25 17:47:56.000000000","message":"This is going to be a lot easier to take a particular service in question and map it\u0027s flow.\n\nFor instance, right now all services are explicitly stopped before upgrades happen. How does it look for a service not being stopped before upgrade. How does the upgrade order look? How does the removal of dependencies while a service is running look and cause not cause issues.\n\nI think that patch series as a POC needs to be sketched out, and we need to figure out how to bin applications into this without making the grenade codebase too unweildly.","commit_id":"8e5875b639a19ec66db3b850c21beccc7e224534"},{"author":{"_account_id":17716,"name":"Luz Cazares","email":"luz.cazares@intel.com","username":"luzcazares"},"change_message_id":"85a61197dcb8d0b1cf0024003d4288cdd1c308bf","unresolved":false,"context_lines":[{"line_number":34,"context_line":"      mentioned above."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"* Introduce new reporting metrics to prove the api was, indeed,"},{"line_number":37,"context_line":"  available and functional during the upgrade."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":""},{"line_number":40,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a461143_fe51bf0f","line":37,"in_reply_to":"3a461143_786246da","updated":"2017-01-25 18:07:35.000000000","message":"Sean I\u0027m working on a separate spec to introduce the \"rolling upgrade\" mechanism (defined by each team such as Nova: http://docs.openstack.org/developer/nova/upgrade.html#rolling-upgrade-process)  instead of turning all services at once.\nUpgrade order at the projects level is still an unknown, initially will try existing grenade order.\nAgree on the POC, lets talk further","commit_id":"8e5875b639a19ec66db3b850c21beccc7e224534"},{"author":{"_account_id":9234,"name":"Steve Heyman","email":"steve@heyman.com","username":"hockeynut"},"change_message_id":"3d4c1fc46d39d9a212febbd5e13936aa44e7ed18","unresolved":false,"context_lines":[{"line_number":34,"context_line":"      mentioned above."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"* Introduce new reporting metrics to prove the api was, indeed,"},{"line_number":37,"context_line":"  available and functional during the upgrade."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":""},{"line_number":40,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a461143_8774eecf","line":37,"in_reply_to":"3a461143_fe51bf0f","updated":"2017-01-25 19:18:12.000000000","message":"Thanks for the comments.  This spec is meant to start exactly this conversation.","commit_id":"8e5875b639a19ec66db3b850c21beccc7e224534"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"b0860afbcaf9021af238faf2747ced114d661e46","unresolved":false,"context_lines":[{"line_number":16,"context_line":"zero-downtime upgrades.  Compared to rolling upgrades, which may"},{"line_number":17,"context_line":"require the API to be unavailable for a small period of time, a"},{"line_number":18,"context_line":"zero-downtime upgrade maintains API uptime throughout the"},{"line_number":19,"context_line":"upgrade process."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Proposed change"},{"line_number":22,"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":7,"id":"1a430d35_93f02093","line":19,"updated":"2017-02-07 19:41:13.000000000","message":"You could link directly to the tag for additional context here, as the outcome of this spec will likely be exactly what the TC uses to assert and maintain the tag:\n\n  https://governance.openstack.org/tc/reference/tags/assert_supports-zero-downtime-upgrade.html","commit_id":"ea0c5a75f01fb6e8194ea66f3f6b34a91976c2a7"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"b0860afbcaf9021af238faf2747ced114d661e46","unresolved":false,"context_lines":[{"line_number":23,"context_line":""},{"line_number":24,"context_line":"* Introduce two new phases into the Grenade basic flow"},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"  * Start API uptime validation."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"    * This will allow one (or more) tests to be run over"},{"line_number":29,"context_line":"      time while an upgrade is in process"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a430d35_d31388b6","line":26,"updated":"2017-02-07 19:41:13.000000000","message":"Would uptime calculations be \"scoped\" to individual services being upgraded, or would all uptime metrics be collected throughout the upgrade process, regardless of which service is being upgraded?\n\nI think both approaches have their own merits, but I\u0027d like to be clear about which we\u0027re pursuing here. In the shorter term, measuring the downtime of each service (how long their offline upgrade procedure take) will highlight which services have unreasonably extended downtime. In the longer term, testing every service constantly might help us catch faulty inter-dependencies between services while they\u0027re being upgraded.","commit_id":"ea0c5a75f01fb6e8194ea66f3f6b34a91976c2a7"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"b0860afbcaf9021af238faf2747ced114d661e46","unresolved":false,"context_lines":[{"line_number":28,"context_line":"    * This will allow one (or more) tests to be run over"},{"line_number":29,"context_line":"      time while an upgrade is in process"},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"  * Stop API uptime validation"},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"    * This will stop any tests that were started in the phase"},{"line_number":34,"context_line":"      mentioned above."}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a430d35_532878e2","line":31,"updated":"2017-02-07 19:41:13.000000000","message":"Same as above, but specify that it\u0027d be after the upgrade process is complete.","commit_id":"ea0c5a75f01fb6e8194ea66f3f6b34a91976c2a7"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"b0860afbcaf9021af238faf2747ced114d661e46","unresolved":false,"context_lines":[{"line_number":50,"context_line":""},{"line_number":51,"context_line":"The focus for this spec is control plane availability.  Data plane"},{"line_number":52,"context_line":"availability could possibly use a similar mechanism but is currently"},{"line_number":53,"context_line":"beyond the scope of this document."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"A POC has been created[2] showing how the API uptime flow will be"},{"line_number":56,"context_line":"implemented:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a430d35_ee889b73","line":53,"updated":"2017-02-07 19:41:13.000000000","message":"+1 I\u0027ve been working with the TC to land a separate project tag for that as well (and I agree it deserves it\u0027s own spec \u0026 discussion for asserting it): https://review.openstack.org/#/c/404361/","commit_id":"ea0c5a75f01fb6e8194ea66f3f6b34a91976c2a7"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"b0860afbcaf9021af238faf2747ced114d661e46","unresolved":false,"context_lines":[{"line_number":53,"context_line":"beyond the scope of this document."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"A POC has been created[2] showing how the API uptime flow will be"},{"line_number":56,"context_line":"implemented:"},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"grenaderc"},{"line_number":59,"context_line":"  * added new configuration option called API_UPTIME_VALIDATION"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a430d35_0e24075e","line":56,"updated":"2017-02-07 19:41:13.000000000","message":"From personal experience, I actually think the \"implementation\" section should stop here. The following details are too detailed for a spec, and tend to spur more bikeshedding over naming (like -1\u0027ing for RUN_TARGET being mispeled in L72) than they do constructive feedback on the overall direction. Focus on communicating the major milestones to implementing a strategic change (i.e. the \"work items\" section), rather than the details of how it\u0027ll be done (which is precisely redundant with the code).","commit_id":"ea0c5a75f01fb6e8194ea66f3f6b34a91976c2a7"}]}