)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"f8683658e63d06cb34d8276b454a07896c5d75b2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8e27fcbe_cc75beab","updated":"2022-02-11 10:36:41.000000000","message":"Great writeup! Small nit inline","commit_id":"b39ba6894b0952dc501845f503074f9ccc04a0ab"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"f61c2e4e962cc092c9c7a341cfd12267e0fa374b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"b8c15bbe_687798a4","updated":"2022-02-12 17:59:18.000000000","message":"Thanks for posting something specific that we can criticize. 😊  Some observations inline.  I\u0027ll have to see what the Cinder project team thinks about it.","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":6476,"name":"Thomas Goirand","email":"thomas@goirand.fr","username":"thomas-goirand"},"change_message_id":"378c253b1ec9390f34318fe7736c75b3d375c739","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ab1a7cab_e79fb103","updated":"2022-02-20 22:49:37.000000000","message":"I don\u0027t like this idea. Basically, this means that for half of the release, we will care less about quality. We should therefore either choose to stay as we are, or move to a 1 year cadence. I\u0027m opinionated toward the later.\n\nIf we are to have this proposal move forward, what about having a \"tick\" every 4 releases? From the distribution point of view, this makes some kind of \"LTS\" releases, that we can upgrade to, without using the intermediary releases. This fits perfectly the Ubuntu and Debian release model (which is aligned on a 2 years release cycle). Having a \"tick\" every year doesn\u0027t address the main concern of upgradability from the distribution point of view.","commit_id":"47ec5acfb78cb37b12641e27c7375362a904c14e"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"82165d10042ac1eb96b82d8e19101134dc02e83e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"a7f10613_fd273cfc","in_reply_to":"ab1a7cab_e79fb103","updated":"2022-02-21 15:00:05.000000000","message":"\u003e I don\u0027t like this idea. Basically, this means that for half of the release, we will care less about quality. \n\nI don\u0027t think this says that *at all*. Quality has to remain at least where it is today, as we continue testing upgrades in the same way between each adjacent release. This doesn\u0027t remove any restrictions, or make the tock releases less important. It purely removes the ability to do things that assume you\u0027re only upgrading from the previous release. If anything, it requires a more holistic view of upgrade-related things to consider a wider window. To me, that\u0027s *higher* quality, not *lower*.\n\n\u003e If we are to have this proposal move forward, what about having a \"tick\" every 4 releases? From the distribution point of view, this makes some kind of \"LTS\" releases, that we can upgrade to, without using the intermediary releases. This fits perfectly the Ubuntu and Debian release model (which is aligned on a 2 years release cycle). Having a \"tick\" every year doesn\u0027t address the main concern of upgradability from the distribution point of view.\n\nI\u0027m not sure how to reconcile \"one tick-tock makes quality lower\" but \"two makes quality higher\". However, a one-year tick-tock gives us additional functionality without a major change to what we\u0027re currently doing. If it is too difficult for too little gain, we can just drop the tick-tock meaning and continue doing what we were doing (unlike an actual change to the cycle length). If it is beneficial, and the tock releases become unimportant, we can drop them and fall back to a single release per year. If everything is useful, we could move to one tick for every four as you describe. However, I think moving to any of those eventualities immediately will be too destabilizing and severe of a change right off the line.","commit_id":"47ec5acfb78cb37b12641e27c7375362a904c14e"},{"author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"change_message_id":"3c00a481c9eeb41a4b74b3dc2b2778027f80877f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"d9f568d0_bbf00eec","updated":"2022-02-25 16:34:29.000000000","message":"(Despite the above concerns, I think this is a great step forward, not backward.)","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":6476,"name":"Thomas Goirand","email":"thomas@goirand.fr","username":"thomas-goirand"},"change_message_id":"5832b1779819bcaca7b66370d4c89a9d978707a9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"da34a2e2_b105b9c7","updated":"2022-02-26 09:57:24.000000000","message":"Considering what Dan Smith replied to me (ie: that the current tick-tock thingy is a nice step forward, going on the direction of a 2 years thingy), I change my mind and approve.\n\nHopefully, after a few tick-tock cycle, everyone will be confident to move this to a tick-tock-tock-tock cycle! 😊","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":7198,"name":"Jay Bryant","email":"jungleboyj@electronicjungle.net","username":"jsbryant"},"change_message_id":"da80ca8d518b1b75fbd234536fad006a9c631cd3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"7967373e_5da67630","updated":"2022-02-24 16:35:11.000000000","message":"I think this is well written and explains things pretty well.  Thanks Dan!","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":2033,"name":"Belmiro Moreira","email":"moreira.belmiro.email.lists@gmail.com","username":"moreira-belmiro-email-lists"},"change_message_id":"b5e69294fe7a5d9c2aca506d36d9d946e60ecea1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"a2c28861_903fe512","updated":"2022-02-22 10:22:54.000000000","message":"Looks good to me.\nI believe this proposal is a great move forward for the release cadence and it attends to the most community concerns.\n","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":6476,"name":"Thomas Goirand","email":"thomas@goirand.fr","username":"thomas-goirand"},"change_message_id":"1d1e1e99cc1167e07c8b6d23b52b4315651fdc1c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"11fcc263_aa28452f","updated":"2022-02-24 08:30:41.000000000","message":"Ok, then I\u0027m going to rephrase, since I got the wrong comment on my comment, hoping to make it more clear...\n\nIt is my opinion that offering the possibility to skip just *one* release isn\u0027t useful from the downstream distribution point of view (ie: Debian \u0026 Ubuntu), and it will only make things more complicated upstream. Having the possibility to skip 3 (and have a 2 years release cycle aligned with the distros) would be VERY nice.\n\nFrom the operator perspective, skipping one is probably easier, when one wants to upgrade from N to N+2, because of not having to go through N+1. But that\u0027s kind of a very limited improvement. What would help is a LTS release that would be supported for longer time (like: if the last tick release every 4 releases was supported for 3 or 4 years, for example, matching what we do in distributions).\n\nI\u0027m very aware that what I\u0027m saying is difficult to achieve upstream, especially when dealing with the CI, and back-porting patches. But if we want an improvement from the user perspective, that\u0027s what we need to do. Doing the tick-tock thingy as proposed isn\u0027t improving anything: neither from the user perspective, neither from the upstream point of view. It just make db migrations more difficult to maintain upstream.\n\nI\u0027m therefore still voting against...","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"change_message_id":"9699690e1d77f33eded873a6dc699fde01652d02","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"17c57e6b_1e99073b","updated":"2022-02-25 16:33:44.000000000","message":"Sorry for late reaction, please find my inline comments.\n\nAnd also one general comment - would TC allow select projects to only release ticks?","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"9ee226c468c803652cee233147880e38c676d50b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"5038660f_cc411178","updated":"2022-02-25 21:27:37.000000000","message":"Started the amendment here:\n\nhttps://review.opendev.org/c/openstack/governance/+/831052\n\nThanks!","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"83b4b5a560452f856a2b541c37fabe2edd00d619","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"9dc0fa90_007554fe","updated":"2022-02-21 18:24:15.000000000","message":"Thanks Gorka!","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"44309f4884a1caaa89d5fb2544ffe51d3246bf92","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"daba505f_55386b0a","updated":"2022-02-25 18:48:47.000000000","message":"Thanks for the attention yoctozepto!","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":9535,"name":"Gorka Eguileor","email":"geguileo@redhat.com","username":"Gorka"},"change_message_id":"41b47052ea02717efcde5c71e0b13121979a1fc0","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"3d16bce0_26a11eb6","updated":"2022-02-21 18:15:18.000000000","message":"Thanks for the changes. It looks good to me.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"8dea9fb8e5f377b1d83767ccad202a4a07fd4979","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"c4124fd9_c3316774","updated":"2022-02-28 16:44:15.000000000","message":"This is good to go now. and we will continue work on documentation/testing updates as per this new release model.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"512e093b71cab7e5d814624fd1360dc88df86987","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"a512d927_cb0c74da","updated":"2022-02-21 17:47:05.000000000","message":"This looks good to me.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"5379b7c0acca6dc5ae159e84f3edce640bd0fa2d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"b5ba0594_3d6b487b","updated":"2022-02-22 19:17:49.000000000","message":"lgtm, thanks. This is good proposal and yes we need few more updates in deprecation document, testing runtime document etc which can be done once we merge this resolution. This is in good shape as making the decision and implementation/more documentation can be updated/added later.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fd404aca9dc2b6487916553c5c3b15fe6b5fb8a4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"1577a17a_24e1742d","in_reply_to":"11fcc263_aa28452f","updated":"2022-02-24 15:24:26.000000000","message":"Okay, fair enough. Without taking a big sudden change to our release process (i.e. going from 6mo and no real LTS to a 4-year LTS), this seems like a step that gives us a lot of options in the future. Perhaps expanding tick-tock to tick-tock-tock will not be hard after some experience, and then from there to what you describe. We have to start somewhere and this seems like a reasonable first step.\n\nBut, your opinion is noted, thanks!","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3fc3d59d8c643572ddf23f01c19fcf51d7b391f6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"61ab21ec_0c899db8","in_reply_to":"17c57e6b_1e99073b","updated":"2022-02-25 16:44:16.000000000","message":"That\u0027s an interesting thought, but I think that would imply more work for CI and release, to make sure that we\u0027re testing the last tick of (say) glance with the master of all the rest of the projects. I don\u0027t know the details of how we handle projects that do uncoordinated releases today, so maybe not a big deal, I dunno.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"change_message_id":"5dfd04280e51415a9ea11e5f753f12e56f20e7e2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"718918af_7a97d514","in_reply_to":"61ab21ec_0c899db8","updated":"2022-02-25 16:50:40.000000000","message":"Yup, it\u0027s more a loose thought or even food for thought for the next generation of TC. 😊","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"change_message_id":"913a9f412ca83cba8b62699c2e85b940fff7adea","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"92230d8f_dc79d307","in_reply_to":"da34a2e2_b105b9c7","updated":"2022-02-26 10:06:25.000000000","message":"++, that would make both Debian and Ubuntu happy, the obvious downside is with deprecations and drops but maybe then we could do like distros - there are major changes between LTSs - allow drops between ticks, if announced on the previous tick or not-the-last tock.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"}],"resolutions/20220210-release-cadence-adjustment.rst":[{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"f8683658e63d06cb34d8276b454a07896c5d75b2","unresolved":true,"context_lines":[{"line_number":119,"context_line":"B       tock Y,Z,A     W,X"},{"line_number":120,"context_line":"C       tick A,B,C     W,X,Y,Z"},{"line_number":121,"context_line":"D       tock A,B,C,D   X,Y,Z"},{"line_number":122,"context_line":"E       tick C,D,E     Y,Z,A"},{"line_number":123,"context_line":"F       tock C,D,E,F   Z,A,B"},{"line_number":124,"context_line":"G       tick E,F,G     A,B,C"},{"line_number":125,"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"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fda791d1_b42e5751","line":122,"range":{"start_line":122,"start_character":23,"end_line":122,"end_character":28},"updated":"2022-02-11 10:36:41.000000000","message":"You mean Y,Z,A,B ?","commit_id":"b39ba6894b0952dc501845f503074f9ccc04a0ab"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5859fef924fa3764eed3f061c81fe2c61addb682","unresolved":false,"context_lines":[{"line_number":119,"context_line":"B       tock Y,Z,A     W,X"},{"line_number":120,"context_line":"C       tick A,B,C     W,X,Y,Z"},{"line_number":121,"context_line":"D       tock A,B,C,D   X,Y,Z"},{"line_number":122,"context_line":"E       tick C,D,E     Y,Z,A"},{"line_number":123,"context_line":"F       tock C,D,E,F   Z,A,B"},{"line_number":124,"context_line":"G       tick E,F,G     A,B,C"},{"line_number":125,"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"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e2f6608b_72a64438","line":122,"range":{"start_line":122,"start_character":23,"end_line":122,"end_character":28},"in_reply_to":"f5226b5b_0caf4cfb","updated":"2022-02-14 18:43:23.000000000","message":"Done","commit_id":"b39ba6894b0952dc501845f503074f9ccc04a0ab"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8535b3fd70972475541a2931db67a0ece326475d","unresolved":true,"context_lines":[{"line_number":119,"context_line":"B       tock Y,Z,A     W,X"},{"line_number":120,"context_line":"C       tick A,B,C     W,X,Y,Z"},{"line_number":121,"context_line":"D       tock A,B,C,D   X,Y,Z"},{"line_number":122,"context_line":"E       tick C,D,E     Y,Z,A"},{"line_number":123,"context_line":"F       tock C,D,E,F   Z,A,B"},{"line_number":124,"context_line":"G       tick E,F,G     A,B,C"},{"line_number":125,"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"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f5226b5b_0caf4cfb","line":122,"range":{"start_line":122,"start_character":23,"end_line":122,"end_character":28},"in_reply_to":"fda791d1_b42e5751","updated":"2022-02-11 14:48:11.000000000","message":"Ah, yep, especially since it\u0027s in the lists below. I was not really being too obsessive over this column because EM is not really very hard and fast in terms of how long we need to support things (see footnote) but it obviously needs to be consistent :)","commit_id":"b39ba6894b0952dc501845f503074f9ccc04a0ab"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"f61c2e4e962cc092c9c7a341cfd12267e0fa374b","unresolved":true,"context_lines":[{"line_number":1,"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"},{"line_number":2,"context_line":" 2022-02-10 Release Cadence Adjustment"},{"line_number":3,"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"},{"line_number":4,"context_line":""},{"line_number":5,"context_line":"History"},{"line_number":6,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1abb60a4_fcae2df8","line":3,"range":{"start_line":3,"start_character":39,"end_line":3,"end_character":40},"updated":"2022-02-12 17:59:18.000000000","message":"super-nit: the lack of symmetry here (1 space in front, 2 behind) is killing me, though AFAIK, the only requirement for ReST is that the overline and underline have to be the same length and at least as long as the text.","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5859fef924fa3764eed3f061c81fe2c61addb682","unresolved":false,"context_lines":[{"line_number":1,"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"},{"line_number":2,"context_line":" 2022-02-10 Release Cadence Adjustment"},{"line_number":3,"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"},{"line_number":4,"context_line":""},{"line_number":5,"context_line":"History"},{"line_number":6,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"b9e10435_5e165926","line":3,"range":{"start_line":3,"start_character":39,"end_line":3,"end_character":40},"in_reply_to":"1abb60a4_fcae2df8","updated":"2022-02-14 18:43:23.000000000","message":"I copied this style from another resolution in the tree, FWIW, but sure.","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"f61c2e4e962cc092c9c7a341cfd12267e0fa374b","unresolved":true,"context_lines":[{"line_number":7,"context_line":""},{"line_number":8,"context_line":"Openstack has historically used a six month release cycle cadence for"},{"line_number":9,"context_line":"the projects which participate in the coordinated release. Further,"},{"line_number":10,"context_line":"upgrades were tested and supported between two adjacent releases only,"},{"line_number":11,"context_line":"requiring deployers and distributions to either upgrade every six"},{"line_number":12,"context_line":"months to stay current, or perform Fast Forward Upgrades (FFUs) to"},{"line_number":13,"context_line":"move between non-adjacent releases at runtime. The latter is an"}],"source_content_type":"text/x-rst","patch_set":2,"id":"95c04dad_6f2ffb18","line":10,"range":{"start_line":10,"start_character":43,"end_line":10,"end_character":69},"updated":"2022-02-12 17:59:18.000000000","message":"Somehow you need to make clear that we\u0027re excluding intermediate releases here, which I know you are, but the assert:follows-standard-deprecation tag description (which AFAIK is the canonical place to find the standard deprecation policy) takes into account intermediate releases (which is one reason why that doc is so hard to follow--also, it was written in the heady days when there were so many people working on openstack that changes were happening so fast that operators couldn\u0027t wait to get their hands on intermediate releases--pretty sure that\u0027s not the case any more).","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5859fef924fa3764eed3f061c81fe2c61addb682","unresolved":false,"context_lines":[{"line_number":7,"context_line":""},{"line_number":8,"context_line":"Openstack has historically used a six month release cycle cadence for"},{"line_number":9,"context_line":"the projects which participate in the coordinated release. Further,"},{"line_number":10,"context_line":"upgrades were tested and supported between two adjacent releases only,"},{"line_number":11,"context_line":"requiring deployers and distributions to either upgrade every six"},{"line_number":12,"context_line":"months to stay current, or perform Fast Forward Upgrades (FFUs) to"},{"line_number":13,"context_line":"move between non-adjacent releases at runtime. The latter is an"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a8f1587_b75d8407","line":10,"range":{"start_line":10,"start_character":43,"end_line":10,"end_character":69},"in_reply_to":"95c04dad_6f2ffb18","updated":"2022-02-14 18:43:23.000000000","message":"Okay I\u0027ve added \"coordinated\" in a couple places, so hopefully that will make it clearer.","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"f61c2e4e962cc092c9c7a341cfd12267e0fa374b","unresolved":true,"context_lines":[{"line_number":52,"context_line":"supported between adjacent releases. The TC will designate releases in"},{"line_number":53,"context_line":"a tick-tock arrangement, such that every other release will be"},{"line_number":54,"context_line":"considered to be a \"tick\" release. Upgrades will be supported between"},{"line_number":55,"context_line":"tick releases, in addition to between tick and tock. Deployments"},{"line_number":56,"context_line":"wishing to stay on the six-month cycle will deploy every tick and tock"},{"line_number":57,"context_line":"release as they always have. Deployments wishing to move to a one year"},{"line_number":58,"context_line":"upgrade cycle will synchronize on a tick release, and then skip the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"42419834_16a6611b","line":55,"range":{"start_line":55,"start_character":15,"end_line":55,"end_character":51},"updated":"2022-02-12 17:59:18.000000000","message":"... plus, tock to the next tick, right?  I think this would be more clear if you just say that we retain the commitment that you will always be able to upgrade from release n to release n+1, regardless of where n falls on the tick/tock clock.  Otherwise it sounds like the poor suckers who upgrade to tock will be left hanging.","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5859fef924fa3764eed3f061c81fe2c61addb682","unresolved":false,"context_lines":[{"line_number":52,"context_line":"supported between adjacent releases. The TC will designate releases in"},{"line_number":53,"context_line":"a tick-tock arrangement, such that every other release will be"},{"line_number":54,"context_line":"considered to be a \"tick\" release. Upgrades will be supported between"},{"line_number":55,"context_line":"tick releases, in addition to between tick and tock. Deployments"},{"line_number":56,"context_line":"wishing to stay on the six-month cycle will deploy every tick and tock"},{"line_number":57,"context_line":"release as they always have. Deployments wishing to move to a one year"},{"line_number":58,"context_line":"upgrade cycle will synchronize on a tick release, and then skip the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"e541fbbc_9efb99b9","line":55,"range":{"start_line":55,"start_character":15,"end_line":55,"end_character":51},"in_reply_to":"42419834_16a6611b","updated":"2022-02-14 18:43:23.000000000","message":"Yes, I think \"between tick and tock\" doesn\u0027t convey direction as much as something like \"from tick to tock\", but I\u0027ll add something here.","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"9960fb32a6a17e3004dbd4352eb93124ae44d475","unresolved":true,"context_lines":[{"line_number":92,"context_line":"   still require an FFU style arrangement, but where tick C is the"},{"line_number":93,"context_line":"   only intermediate step required."},{"line_number":94,"context_line":"#. **Deprecations**: Projects currently deprecate features and config"},{"line_number":95,"context_line":"   for at least one cycle before removal. This change only affects"},{"line_number":96,"context_line":"   *when* that can happen, so that no required changes occur in a tock"},{"line_number":97,"context_line":"   release which may be skipped."},{"line_number":98,"context_line":"#. **Support**: We will expect to support both the most recent tick"},{"line_number":99,"context_line":"   release as well as the one prior. During a tock release, that would"},{"line_number":100,"context_line":"   effectively be similar to what we support today, which is 18 months"}],"source_content_type":"text/x-rst","patch_set":2,"id":"0285cb5c_486e6125","line":97,"range":{"start_line":95,"start_character":41,"end_line":97,"end_character":32},"updated":"2022-02-11 23:13:29.000000000","message":"When is it? I mean it isn\u0027t obvious to the reader here 😊\n\nWe have three deprecation related guidelines:\n\nminor changes happening at the beginning of a cycle -- 1 cycle deprecation, support can be dropped in the next release\n\nmajor changes happening at the beginning of a cycle -- 2 cycle deprecation, support can be dropped at the beginning of the third release\n\nminor/major changes happening at the end of a cycle -- add one cycle to the above guidance\n\nFFU upgrade steps by deployers so far have accommodated these models. \n\nWould we redo these guidelines to specify that only tick releases are considered while waiting/performing removals?\n\ni.e., \n\nif minor deprecation occurs at the beginning of a tick, wait until next tick for removal (i.e., support something for two cycles: tick, tock)\nif major deprecation occurs at the beginning of a tick, perform removal at the beginning of the third tick (i.e., support something for 4 normal cycles: tick, tock, tick, tock)","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"f61c2e4e962cc092c9c7a341cfd12267e0fa374b","unresolved":true,"context_lines":[{"line_number":92,"context_line":"   still require an FFU style arrangement, but where tick C is the"},{"line_number":93,"context_line":"   only intermediate step required."},{"line_number":94,"context_line":"#. **Deprecations**: Projects currently deprecate features and config"},{"line_number":95,"context_line":"   for at least one cycle before removal. This change only affects"},{"line_number":96,"context_line":"   *when* that can happen, so that no required changes occur in a tock"},{"line_number":97,"context_line":"   release which may be skipped."},{"line_number":98,"context_line":"#. **Support**: We will expect to support both the most recent tick"},{"line_number":99,"context_line":"   release as well as the one prior. During a tock release, that would"},{"line_number":100,"context_line":"   effectively be similar to what we support today, which is 18 months"}],"source_content_type":"text/x-rst","patch_set":2,"id":"592664df_549fa907","line":97,"range":{"start_line":95,"start_character":41,"end_line":97,"end_character":32},"in_reply_to":"0285cb5c_486e6125","updated":"2022-02-12 17:59:18.000000000","message":"@Goutham: I agree that the guidelines need to be rewritten (independently of Dan\u0027s proposal here).  I don\u0027t see the 3 distinctions you make here (though maybe I\u0027m looking in the wrong place):\n    https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html#requirements\n\nThat doc was written in the days when intermediate releases were required, so the time length between releases assumed in that document is different from cycle length (hence the 3 month rule).\n\nNow that the major projects don\u0027t do intermediate releases any more, we should standardize on the coordinated release as the only release that matters for the purposes of deprecations.  I don\u0027t think anyone runs openstack from trunk any more, so I don\u0027t see the point of the 3 month rule.  I think we should simply state: when something is marked as deprecated in coordinated release N, it will persist in stable/N but cannot be expected to be present in coordinated release N+1 (unless the deprecation announcement specifies a longer period, which is allowed but not required (except for features included in the interop guidelines, whose removal timeline needs to be worked out separately anyway)).  But no guarantees about when during the development cycle the removal will happen.\n\n@Dan: A deprecation is only useful when people know about it.  If we go to the tick/tock model, then we are encouraging people to ignore tock releases (which is fine, that\u0027s the whole point).  But I think that means that we can\u0027t expect deployers to be aware of deprecations that happen in tock releases.  Hence, we will have to allow deprecations to happen *only* in tick releases, with the idea that when you upgrade to tick2 (whether from tick1 or tock1), that\u0027s when any required db changes/migrations will take place.  (I think this is all implied by your \"This change only affects *when* that can happen\", but it\u0027s worth stating explicitly.)\n\nIn any case, I\u0027ll be interested in your response to Goutham.","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5859fef924fa3764eed3f061c81fe2c61addb682","unresolved":false,"context_lines":[{"line_number":92,"context_line":"   still require an FFU style arrangement, but where tick C is the"},{"line_number":93,"context_line":"   only intermediate step required."},{"line_number":94,"context_line":"#. **Deprecations**: Projects currently deprecate features and config"},{"line_number":95,"context_line":"   for at least one cycle before removal. This change only affects"},{"line_number":96,"context_line":"   *when* that can happen, so that no required changes occur in a tock"},{"line_number":97,"context_line":"   release which may be skipped."},{"line_number":98,"context_line":"#. **Support**: We will expect to support both the most recent tick"},{"line_number":99,"context_line":"   release as well as the one prior. During a tock release, that would"},{"line_number":100,"context_line":"   effectively be similar to what we support today, which is 18 months"}],"source_content_type":"text/x-rst","patch_set":2,"id":"62de02bd_43acf2a8","line":97,"range":{"start_line":95,"start_character":41,"end_line":97,"end_character":32},"in_reply_to":"592664df_549fa907","updated":"2022-02-14 18:43:23.000000000","message":"Yes, I think the simplest way to put this is \"the same rules as today in terms of deprecation cycle, except only \"tick\" releases count.\n\nI can see it being useful to also say that you can\u0027t start a deprecation in a tock release if the signal comes only there and only through a reno, as people only running tick releases might never see them. I\u0027ll try to add some words.","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"f61c2e4e962cc092c9c7a341cfd12267e0fa374b","unresolved":true,"context_lines":[{"line_number":99,"context_line":"   release as well as the one prior. During a tock release, that would"},{"line_number":100,"context_line":"   effectively be similar to what we support today, which is 18 months"},{"line_number":101,"context_line":"   of \"maintained\" releases. See the example sequence below."},{"line_number":102,"context_line":"#. **Rolling Upgrades**: This scheme does not necessarily dictate that"},{"line_number":103,"context_line":"   live or rolling upgrades need to be supported between tick"},{"line_number":104,"context_line":"   releases. Meaning RPC compatibility between N to N-1 guarantees can"},{"line_number":105,"context_line":"   remain, resulting in deployments that are on a tick-tick release"}],"source_content_type":"text/x-rst","patch_set":2,"id":"be6745c2_991bf70d","line":102,"range":{"start_line":102,"start_character":37,"end_line":102,"end_character":65},"updated":"2022-02-12 17:59:18.000000000","message":"I wonder about this.  You don\u0027t state explicitly that we must do it, but I\u0027m not sure about how this would work out in practice.","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"change_message_id":"5dfd04280e51415a9ea11e5f753f12e56f20e7e2","unresolved":false,"context_lines":[{"line_number":99,"context_line":"   release as well as the one prior. During a tock release, that would"},{"line_number":100,"context_line":"   effectively be similar to what we support today, which is 18 months"},{"line_number":101,"context_line":"   of \"maintained\" releases. See the example sequence below."},{"line_number":102,"context_line":"#. **Rolling Upgrades**: This scheme does not necessarily dictate that"},{"line_number":103,"context_line":"   live or rolling upgrades need to be supported between tick"},{"line_number":104,"context_line":"   releases. Meaning RPC compatibility between N to N-1 guarantees can"},{"line_number":105,"context_line":"   remain, resulting in deployments that are on a tick-tick release"}],"source_content_type":"text/x-rst","patch_set":2,"id":"433098d0_f86fce9b","line":102,"range":{"start_line":102,"start_character":37,"end_line":102,"end_character":65},"in_reply_to":"1c81507c_8e54c7dc","updated":"2022-02-25 16:50:40.000000000","message":"Thanks, that\u0027s a good explanation.","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"change_message_id":"9699690e1d77f33eded873a6dc699fde01652d02","unresolved":true,"context_lines":[{"line_number":99,"context_line":"   release as well as the one prior. During a tock release, that would"},{"line_number":100,"context_line":"   effectively be similar to what we support today, which is 18 months"},{"line_number":101,"context_line":"   of \"maintained\" releases. See the example sequence below."},{"line_number":102,"context_line":"#. **Rolling Upgrades**: This scheme does not necessarily dictate that"},{"line_number":103,"context_line":"   live or rolling upgrades need to be supported between tick"},{"line_number":104,"context_line":"   releases. Meaning RPC compatibility between N to N-1 guarantees can"},{"line_number":105,"context_line":"   remain, resulting in deployments that are on a tick-tick release"}],"source_content_type":"text/x-rst","patch_set":2,"id":"71cc19ee_ba619d18","line":102,"range":{"start_line":102,"start_character":37,"end_line":102,"end_character":65},"in_reply_to":"23a7228f_290dc248","updated":"2022-02-25 16:33:44.000000000","message":"I think not requiring live upgrades to be supported may effectively render this proposal useless for deployers because they, nonetheless, prepare to avoid downtime, not embrace it.","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3fc3d59d8c643572ddf23f01c19fcf51d7b391f6","unresolved":true,"context_lines":[{"line_number":99,"context_line":"   release as well as the one prior. During a tock release, that would"},{"line_number":100,"context_line":"   effectively be similar to what we support today, which is 18 months"},{"line_number":101,"context_line":"   of \"maintained\" releases. See the example sequence below."},{"line_number":102,"context_line":"#. **Rolling Upgrades**: This scheme does not necessarily dictate that"},{"line_number":103,"context_line":"   live or rolling upgrades need to be supported between tick"},{"line_number":104,"context_line":"   releases. Meaning RPC compatibility between N to N-1 guarantees can"},{"line_number":105,"context_line":"   remain, resulting in deployments that are on a tick-tick release"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1c81507c_8e54c7dc","line":102,"range":{"start_line":102,"start_character":37,"end_line":102,"end_character":65},"in_reply_to":"71cc19ee_ba619d18","updated":"2022-02-25 16:44:16.000000000","message":"Nobody currently doing FFU is able to do them live. So my feeling is that anyone interested in only deploying tick releases is already doing a not-live upgrade, and thus this shouldn\u0027t be any sort of regression for them. It brings the benefit of not having to step through the tock releases and thus makes it more likely to stay current.\n\nOf course, we must crawl before we walk - nothing here prevents live from working, now or in the future, but as many projects can\u0027t even do live upgrades I think requiring it would basically be impossible at the moment.","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5859fef924fa3764eed3f061c81fe2c61addb682","unresolved":true,"context_lines":[{"line_number":99,"context_line":"   release as well as the one prior. During a tock release, that would"},{"line_number":100,"context_line":"   effectively be similar to what we support today, which is 18 months"},{"line_number":101,"context_line":"   of \"maintained\" releases. See the example sequence below."},{"line_number":102,"context_line":"#. **Rolling Upgrades**: This scheme does not necessarily dictate that"},{"line_number":103,"context_line":"   live or rolling upgrades need to be supported between tick"},{"line_number":104,"context_line":"   releases. Meaning RPC compatibility between N to N-1 guarantees can"},{"line_number":105,"context_line":"   remain, resulting in deployments that are on a tick-tick release"}],"source_content_type":"text/x-rst","patch_set":2,"id":"23a7228f_290dc248","line":102,"range":{"start_line":102,"start_character":37,"end_line":102,"end_character":65},"in_reply_to":"be6745c2_991bf70d","updated":"2022-02-14 18:43:23.000000000","message":"What do you mean? If we don\u0027t do a multinode grenade job where we leave behind some of the services, then we won\u0027t get stuck if we were to break this capability. In terms of upgrade practicalities, it should be the same as FFU today without the intermediate steps. Any operator currently hopping between non-adjacent releases using FFU (or luck) is already having to shut down services so they don\u0027t have very old things running together with new ones.\n\nI think it\u0027s fine to say that if you want live upgrades, you should stick to the 6-month releases, as you must today. Whether or not we expand our promises to include live support from tick-to-tick (which is a pretty big ask) can be left for the future.","commit_id":"d53285b2a111971e6dd1e0821660f2eb62d45b51"},{"author":{"_account_id":9535,"name":"Gorka Eguileor","email":"geguileo@redhat.com","username":"Gorka"},"change_message_id":"25c64e7d5f4b5ee5c0bb9589a593883085a98966","unresolved":true,"context_lines":[{"line_number":73,"context_line":"\"tick\" releases will be chosen in this way and thus end up with more"},{"line_number":74,"context_line":"focus on those releases for long-term community support."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Details"},{"line_number":77,"context_line":"-------"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"#. **Testing**: Just as we test and guarantee that upgrades are"}],"source_content_type":"text/x-rst","patch_set":3,"id":"10a2aea3_604e11fe","line":76,"range":{"start_line":76,"start_character":0,"end_line":76,"end_character":7},"updated":"2022-02-21 14:02:07.000000000","message":"-1: I think we should add the details of how this affects online data migrations.\n\nWith our current upgrade support (both rolling and FFU) we don\u0027t need to keep online data migrations from the previous release around, so they are removed from the code on each release, but with this new approach we need to keep a part of them around for tick-to-tick upgrades.\n\nSo the online data migration code that is run while the services run can be removed, but the code from the previous release that is run on the manage commands (i.e., cinder-manage db online_data_migrations) needs to be kept around for tick releases (so it has the tock migration).\n\nThese tock data migrations need to be moved so they are run in the \"db sync\" command and they must be run **before** the tick db schema changes happen, otherwise we could be losing data.\n\nAn example of how we would be losing is when renaming a column. With the current mechanism it would go like this:\n\n- Tick#1 is released (N release): DB schema migration creates new column in DB table with online data migration code in manage and service.\n\n- Tick#1 is installed: DB schema creates the new column\n\n- Tick#1 is running for a while: Online data migration code running on the services copies the data from old column to the new one and to keeps them in sync for **resources** that are accessed.\n\n- Tock#1 is released (N+1 release): Online data migrations code is removed and  project code stops using old column.\n\n- Tick#2 is released (N+2 release): DB schema migration drops old column.\n\n- Upgrade from Tick#1 to Tick#2: When Tick#2 DB schema migration is run it deletes the old column and any resource that had not being accessed while Tick#1 was running will either have an empty new column or will crash because the column is set to no longer be nullable.","commit_id":"47ec5acfb78cb37b12641e27c7375362a904c14e"},{"author":{"_account_id":9535,"name":"Gorka Eguileor","email":"geguileo@redhat.com","username":"Gorka"},"change_message_id":"41b47052ea02717efcde5c71e0b13121979a1fc0","unresolved":false,"context_lines":[{"line_number":73,"context_line":"\"tick\" releases will be chosen in this way and thus end up with more"},{"line_number":74,"context_line":"focus on those releases for long-term community support."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Details"},{"line_number":77,"context_line":"-------"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"#. **Testing**: Just as we test and guarantee that upgrades are"}],"source_content_type":"text/x-rst","patch_set":3,"id":"8b281df1_fb587b7d","line":76,"range":{"start_line":76,"start_character":0,"end_line":76,"end_character":7},"in_reply_to":"0abefc14_9a9a4161","updated":"2022-02-21 18:15:18.000000000","message":"\u003e \u003e -1: I think we should add the details of how this affects online data migrations.\n\u003e \u003e \n\u003e \u003e With our current upgrade support (both rolling and FFU) we don\u0027t need to keep online data migrations from the previous release around, so they are removed from the code on each release, but with this new approach we need to keep a part of them around for tick-to-tick upgrades.\n\u003e \n\u003e Correct. I thought it was clear from what I have here, but I\u0027ll add some words in the details section to specifically point this out.\n\nIt is clear for anyone that fully understands the rolling upgrades mechanism, but in my experience there are too many people that don\u0027t, and I also think all projects should implement the same solution for the issue.\n\n\n\u003e \u003e So the online data migration code that is run while the services run can be removed, but the code from the previous release that is run on the manage commands (i.e., cinder-manage db online_data_migrations) needs to be kept around for tick releases (so it has the tock migration).\n\u003e \n\u003e Unless I\u0027m missing something about what you\u0027re describing, you can\u0027t remove either. If you never ran services or tooling from tock, then the in-service migration code in a tock release will have to stick around through the next tick, as none of it would have run if the operator didn\u0027t run any code (management tooling or services) from the tock.\n\nMy bad, I wrote the example incorrectly (hard facepalm). The problem would happen when adding the column and the data migration on the Tock release.\n\n\n\u003e \u003e These tock data migrations need to be moved so they are run in the \"db sync\" command and they must be run **before** the tick db schema changes happen, otherwise we could be losing data.\n\u003e \n\u003e Ah, I think I see what you mean. In the case of expansive schema migrations, it won\u0027t be a problem. If you intermix your contractions together such that they have to run during the schema migration, then sure. However, contractions generally can be put off a long time, so the other alternative is to just schedule them for the following tick from the one that actually migrates the data.\n\nIt\u0027s also about having to carry over online migrations from a Tock release and having to run them before the next Tick\u0027s schema migrations if a column is being dropped.\n\n\n\u003e I\u0027m not sure the above example is complete,\n\nYou are right, it was garbage.\n\n\u003e In nova we usually provide a nova-manage command to push batches of those inactive resource migrations that the operator can run after upgrade at idle time. given that example, you can still \"stop using the old column\" in tock #1, and you can still drop the migration code in tick #1 along with the column itself, if you want. I think it\u0027s fine to tell operators that they have to have \"finished all their homework\" from tick #1 before they can upgrade to tick #2, and that\u0027s usually how we describe it in Nova.\n\nWe have the same in Cinder, but the problem is when/how we run this online data migration from the Tock.\n\nTock\u0027s data migrations must happen **before** Tick#2\u0027s services run, but we didn\u0027t run Tock\u0027s data migrations, and even if we carry them to Tick#2 the online data migration from Tick#2 won\u0027t be before its services are run.\n\n\n\u003e However, the above describes dropping online migration code in a tock, which is what this resolution describes as \"not okay\" for the reason you describe here.\n\nI must have missed something, because I only see this spec referring to feature and config deprecations and I didn\u0027t read anything about database changes.\n\n\n\u003e That said, as you note, this resolution clearly adds some additional accounting for these upgrade things, which will be extra work, no doubt about it. I just think it\u0027s a very manageable amount of additional work with minimal actual change to how things work.\n\nI agree, the amount of work need is minimal, but I just wanted to make sure it gets spelled out so we don\u0027t miss it.\n\nLike you said, we just need to introduce a new restriction: Tick releases cannot drop DB columns or online data migration code, drops must always happen on Tock releases.","commit_id":"47ec5acfb78cb37b12641e27c7375362a904c14e"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"82165d10042ac1eb96b82d8e19101134dc02e83e","unresolved":true,"context_lines":[{"line_number":73,"context_line":"\"tick\" releases will be chosen in this way and thus end up with more"},{"line_number":74,"context_line":"focus on those releases for long-term community support."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Details"},{"line_number":77,"context_line":"-------"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"#. **Testing**: Just as we test and guarantee that upgrades are"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0abefc14_9a9a4161","line":76,"range":{"start_line":76,"start_character":0,"end_line":76,"end_character":7},"in_reply_to":"10a2aea3_604e11fe","updated":"2022-02-21 15:00:05.000000000","message":"\u003e -1: I think we should add the details of how this affects online data migrations.\n\u003e \n\u003e With our current upgrade support (both rolling and FFU) we don\u0027t need to keep online data migrations from the previous release around, so they are removed from the code on each release, but with this new approach we need to keep a part of them around for tick-to-tick upgrades.\n\nCorrect. I thought it was clear from what I have here, but I\u0027ll add some words in the details section to specifically point this out.\n\n\u003e So the online data migration code that is run while the services run can be removed, but the code from the previous release that is run on the manage commands (i.e., cinder-manage db online_data_migrations) needs to be kept around for tick releases (so it has the tock migration).\n\nUnless I\u0027m missing something about what you\u0027re describing, you can\u0027t remove either. If you never ran services or tooling from tock, then the in-service migration code in a tock release will have to stick around through the next tick, as none of it would have run if the operator didn\u0027t run any code (management tooling or services) from the tock.\n\n\u003e These tock data migrations need to be moved so they are run in the \"db sync\" command and they must be run **before** the tick db schema changes happen, otherwise we could be losing data.\n\nAh, I think I see what you mean. In the case of expansive schema migrations, it won\u0027t be a problem. If you intermix your contractions together such that they have to run during the schema migration, then sure. However, contractions generally can be put off a long time, so the other alternative is to just schedule them for the following tick from the one that actually migrates the data.\n\n\u003e An example of how we would be losing is when renaming a column. With the current mechanism it would go like this:\n\u003e \n\u003e - Tick#1 is released (N release): DB schema migration creates new column in DB table with online data migration code in manage and service.\n\u003e \n\u003e - Tick#1 is installed: DB schema creates the new column\n\u003e \n\u003e - Tick#1 is running for a while: Online data migration code running on the services copies the data from old column to the new one and to keeps them in sync for **resources** that are accessed.\n\u003e \n\u003e - Tock#1 is released (N+1 release): Online data migrations code is removed and  project code stops using old column.\n\u003e \n\u003e - Tick#2 is released (N+2 release): DB schema migration drops old column.\n\u003e \n\u003e - Upgrade from Tick#1 to Tick#2: When Tick#2 DB schema migration is run it deletes the old column and any resource that had not being accessed while Tick#1 was running will either have an empty new column or will crash because the column is set to no longer be nullable.\n\nI\u0027m not sure the above example is complete, because nothing in tock #1 describes migrating all the resources that don\u0027t get touched during normal activity, which is what your tick-tick failure scenario describes. However, the above describes dropping online migration code in a tock, which is what this resolution describes as \"not okay\" for the reason you describe here. I think that in any scenario like you describe, you need to have something to ensure that all the resources get migrated, to cover the inactive ones, and that can happen in the background in tick #1. In nova we usually provide a nova-manage command to push batches of those inactive resource migrations that the operator can run after upgrade at idle time. given that example, you can still \"stop using the old column\" in tock #1, and you can still drop the migration code in tick #1 along with the column itself, if you want. I think it\u0027s fine to tell operators that they have to have \"finished all their homework\" from tick #1 before they can upgrade to tick #2, and that\u0027s usually how we describe it in Nova.\n\nThat said, as you note, this resolution clearly adds some additional accounting for these upgrade things, which will be extra work, no doubt about it. I just think it\u0027s a very manageable amount of additional work with minimal actual change to how things work.","commit_id":"47ec5acfb78cb37b12641e27c7375362a904c14e"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"83b4b5a560452f856a2b541c37fabe2edd00d619","unresolved":false,"context_lines":[{"line_number":73,"context_line":"\"tick\" releases will be chosen in this way and thus end up with more"},{"line_number":74,"context_line":"focus on those releases for long-term community support."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Details"},{"line_number":77,"context_line":"-------"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"#. **Testing**: Just as we test and guarantee that upgrades are"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bb483ca7_695d0906","line":76,"range":{"start_line":76,"start_character":0,"end_line":76,"end_character":7},"in_reply_to":"8b281df1_fb587b7d","updated":"2022-02-21 18:24:15.000000000","message":"\u003e \u003e However, the above describes dropping online migration code in a tock, which is what this resolution describes as \"not okay\" for the reason you describe here.\n\u003e \n\u003e I must have missed something, because I only see this spec referring to feature and config deprecations and I didn\u0027t read anything about database changes.\n\nNo, you\u0027re right, it wasn\u0027t clear in there. It was clear in my head because, as you noted, someone with upgrade battle scars would see it as obvious. So, I\u0027m glad you brought it up so it\u0027s in there properly.\n\n\u003e I agree, the amount of work need is minimal, but I just wanted to make sure it gets spelled out so we don\u0027t miss it.\n\u003e \n\u003e Like you said, we just need to introduce a new restriction: Tick releases cannot drop DB columns or online data migration code, drops must always happen on Tock releases.\n\nYep, cool, definitely good to get it in there explicitly.","commit_id":"47ec5acfb78cb37b12641e27c7375362a904c14e"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"2a9f35887ef0fb9ffbafb96130d858533815d8f7","unresolved":true,"context_lines":[{"line_number":125,"context_line":"Release Type Supported EM"},{"line_number":126,"context_line":"A       tick X,Y,Z     W"},{"line_number":127,"context_line":"B       tock Y,Z,A     W,X"},{"line_number":128,"context_line":"C       tick A,B,C     W,X,Y,Z"},{"line_number":129,"context_line":"D       tock A,B,C,D   X,Y,Z"},{"line_number":130,"context_line":"E       tick C,D,E     Y,Z,A,B"},{"line_number":131,"context_line":"F       tock C,D,E,F   Z,A,B"}],"source_content_type":"text/x-rst","patch_set":3,"id":"544b398a_8ab1e50d","line":128,"range":{"start_line":128,"start_character":13,"end_line":128,"end_character":18},"updated":"2022-02-21 21:07:56.000000000","message":"nit: I think it should be Z, A, B here, instead of having Z in EM phase already, shouldn\u0027t it?","commit_id":"47ec5acfb78cb37b12641e27c7375362a904c14e"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"5379b7c0acca6dc5ae159e84f3edce640bd0fa2d","unresolved":true,"context_lines":[{"line_number":125,"context_line":"Release Type Supported EM"},{"line_number":126,"context_line":"A       tick X,Y,Z     W"},{"line_number":127,"context_line":"B       tock Y,Z,A     W,X"},{"line_number":128,"context_line":"C       tick A,B,C     W,X,Y,Z"},{"line_number":129,"context_line":"D       tock A,B,C,D   X,Y,Z"},{"line_number":130,"context_line":"E       tick C,D,E     Y,Z,A,B"},{"line_number":131,"context_line":"F       tock C,D,E,F   Z,A,B"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3b3d64ab_3f0eac43","line":128,"range":{"start_line":128,"start_character":13,"end_line":128,"end_character":18},"in_reply_to":"0ff7b4fc_db1b0ede","updated":"2022-02-22 19:17:49.000000000","message":"yeah, there is always a delay in moving supported release to EM state.\n\nBut as Dan mentioned idea is to support two tick at a time so that we can support the upgrade and backports and for that we need to support in between tock release too. When last supported tick is gone (say in E) tick and tock move together to EM (A and B move to EM together) and next tick is added as supported (so two ticks C and E are in supported). This is because we can support the backport from C-\u003eB-\u003eA.\n\nIn summary, two latest ticks need to be in \u0027Supported\u0027 at any time and any in between tock will also be for backport path to tick.","commit_id":"47ec5acfb78cb37b12641e27c7375362a904c14e"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"e0aa0fccc555014a7d8794d31e277d9cb8202714","unresolved":false,"context_lines":[{"line_number":125,"context_line":"Release Type Supported EM"},{"line_number":126,"context_line":"A       tick X,Y,Z     W"},{"line_number":127,"context_line":"B       tock Y,Z,A     W,X"},{"line_number":128,"context_line":"C       tick A,B,C     W,X,Y,Z"},{"line_number":129,"context_line":"D       tock A,B,C,D   X,Y,Z"},{"line_number":130,"context_line":"E       tick C,D,E     Y,Z,A,B"},{"line_number":131,"context_line":"F       tock C,D,E,F   Z,A,B"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9065204b_e6f3e9a0","line":128,"range":{"start_line":128,"start_character":13,"end_line":128,"end_character":18},"in_reply_to":"3b3d64ab_3f0eac43","updated":"2022-02-23 16:14:39.000000000","message":"Ack","commit_id":"47ec5acfb78cb37b12641e27c7375362a904c14e"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6447efd9a737af3be908bdc8d969733c6fd3b36c","unresolved":true,"context_lines":[{"line_number":125,"context_line":"Release Type Supported EM"},{"line_number":126,"context_line":"A       tick X,Y,Z     W"},{"line_number":127,"context_line":"B       tock Y,Z,A     W,X"},{"line_number":128,"context_line":"C       tick A,B,C     W,X,Y,Z"},{"line_number":129,"context_line":"D       tock A,B,C,D   X,Y,Z"},{"line_number":130,"context_line":"E       tick C,D,E     Y,Z,A,B"},{"line_number":131,"context_line":"F       tock C,D,E,F   Z,A,B"}],"source_content_type":"text/x-rst","patch_set":3,"id":"929066a6_4c66a28c","line":128,"range":{"start_line":128,"start_character":13,"end_line":128,"end_character":18},"in_reply_to":"544b398a_8ab1e50d","updated":"2022-02-21 21:15:16.000000000","message":"No, the proposal here is that once a new tick is out, we support to the previous tick (see the E tick below for example). I think that\u0027s pretty much on-par with what we do today, where sometime after a release is cut, the n-3 release moves to EM. It\u0027s not instantaneous, and the table here doesn\u0027t have room for those details. Meaning, the instant C is out, we don\u0027t immediately nuke Z, but pretty soon after.\n\nThat said, this is really just an example, and the important thing to take away from this table is that adjacent tick releases stay in the support window.","commit_id":"47ec5acfb78cb37b12641e27c7375362a904c14e"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad306dddefa3ee74f3a68fb3620aaca9ae21f3b1","unresolved":false,"context_lines":[{"line_number":125,"context_line":"Release Type Supported EM"},{"line_number":126,"context_line":"A       tick X,Y,Z     W"},{"line_number":127,"context_line":"B       tock Y,Z,A     W,X"},{"line_number":128,"context_line":"C       tick A,B,C     W,X,Y,Z"},{"line_number":129,"context_line":"D       tock A,B,C,D   X,Y,Z"},{"line_number":130,"context_line":"E       tick C,D,E     Y,Z,A,B"},{"line_number":131,"context_line":"F       tock C,D,E,F   Z,A,B"}],"source_content_type":"text/x-rst","patch_set":3,"id":"a9a77441_0fd7a605","line":128,"range":{"start_line":128,"start_character":13,"end_line":128,"end_character":18},"in_reply_to":"9065204b_e6f3e9a0","updated":"2022-02-26 07:29:24.000000000","message":"ok, I got it now. Thx or clarification :)","commit_id":"47ec5acfb78cb37b12641e27c7375362a904c14e"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"652f137f189342cb707a06f201c58e760d706354","unresolved":true,"context_lines":[{"line_number":125,"context_line":"Release Type Supported EM"},{"line_number":126,"context_line":"A       tick X,Y,Z     W"},{"line_number":127,"context_line":"B       tock Y,Z,A     W,X"},{"line_number":128,"context_line":"C       tick A,B,C     W,X,Y,Z"},{"line_number":129,"context_line":"D       tock A,B,C,D   X,Y,Z"},{"line_number":130,"context_line":"E       tick C,D,E     Y,Z,A,B"},{"line_number":131,"context_line":"F       tock C,D,E,F   Z,A,B"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0ff7b4fc_db1b0ede","line":128,"range":{"start_line":128,"start_character":13,"end_line":128,"end_character":18},"in_reply_to":"929066a6_4c66a28c","updated":"2022-02-22 10:59:11.000000000","message":"thanks for making it clear, I think it is important to highlight that even if Z in this case is still there, there is no guarantee that it will be maintained for another cycle (or more) as we do today, but the decision is coordinated in the community.","commit_id":"47ec5acfb78cb37b12641e27c7375362a904c14e"},{"author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"change_message_id":"9699690e1d77f33eded873a6dc699fde01652d02","unresolved":true,"context_lines":[{"line_number":5,"context_line":"History"},{"line_number":6,"context_line":"-------"},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"Openstack has historically used a six month release cycle cadence for"},{"line_number":9,"context_line":"the projects which participate in the coordinated release. Further,"},{"line_number":10,"context_line":"upgrades were tested and supported between two adjacent coordinated"},{"line_number":11,"context_line":"releases only, requiring deployers and distributions to either upgrade"}],"source_content_type":"text/x-rst","patch_set":4,"id":"4feedfe1_48dd7265","line":8,"range":{"start_line":8,"start_character":4,"end_line":8,"end_character":5},"updated":"2022-02-25 16:33:44.000000000","message":"S","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"5379b7c0acca6dc5ae159e84f3edce640bd0fa2d","unresolved":true,"context_lines":[{"line_number":101,"context_line":"   arrangement, with the exception that \"cycle\" refers to a tick-tick"},{"line_number":102,"context_line":"   cycle and not a single pair of adjacent coordinated releases. Since"},{"line_number":103,"context_line":"   the deprecation, waiting, and removal can only happen in tick"},{"line_number":104,"context_line":"   releases, the result is also that the minimum *length* of time that"},{"line_number":105,"context_line":"   things may be deprecated before removal will increase as well."},{"line_number":106,"context_line":"#. **Support**: We will expect to support both the most recent tick"},{"line_number":107,"context_line":"   release as well as the one prior. During a tock release, that would"},{"line_number":108,"context_line":"   effectively be similar to what we support today, which is 18 months"}],"source_content_type":"text/x-rst","patch_set":4,"id":"72c37e7b_fbb0d56b","line":105,"range":{"start_line":104,"start_character":41,"end_line":105,"end_character":65},"updated":"2022-02-22 19:17:49.000000000","message":"in practical it does not increase as we hardly remove the things in immediate cycle :). +1 on considering the deprecation in tick only.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":9535,"name":"Gorka Eguileor","email":"geguileo@redhat.com","username":"Gorka"},"change_message_id":"41b47052ea02717efcde5c71e0b13121979a1fc0","unresolved":false,"context_lines":[{"line_number":114,"context_line":"   schedule requiring some downtime during an upgrade because"},{"line_number":115,"context_line":"   components will be spanning more than two actual releases."},{"line_number":116,"context_line":"#. **Data migrations**: Part of supporting tick-tick upgrades involves"},{"line_number":117,"context_line":"   keeping a stable (read \"compatible\" not \"unchanging\") database"},{"line_number":118,"context_line":"   schema from tick-tick. This includes data migrations which need to"},{"line_number":119,"context_line":"   do work in tick releases, and while they may do work in tock"},{"line_number":120,"context_line":"   releases, the work done in tock releases cannot be"}],"source_content_type":"text/x-rst","patch_set":4,"id":"b5b90e44_0d030a4f","line":117,"range":{"start_line":117,"start_character":0,"end_line":117,"end_character":65},"updated":"2022-02-21 18:15:18.000000000","message":"Thank you for including this.  For the high level view of this document this is perfect.  For cinder contributor I think I\u0027ll document the simple restriction of not dropping things in Tock releases.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"change_message_id":"9699690e1d77f33eded873a6dc699fde01652d02","unresolved":true,"context_lines":[{"line_number":120,"context_line":"   releases, the work done in tock releases cannot be"},{"line_number":121,"context_line":"   *mandatory*. This can be solved by requiring operators to"},{"line_number":122,"context_line":"   (force-)complete data migrations on a source tick before upgrading"},{"line_number":123,"context_line":"   to a target tick, for example."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"Example sequence"},{"line_number":126,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"b3b79cde_a0778198","line":123,"updated":"2022-02-25 16:33:44.000000000","message":"Effectively this means that operators (and deployment projects) might have it harder on them. I would prefer this be on the projects themselves to ensure that standard magic still works.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":9535,"name":"Gorka Eguileor","email":"geguileo@redhat.com","username":"Gorka"},"change_message_id":"41b47052ea02717efcde5c71e0b13121979a1fc0","unresolved":false,"context_lines":[{"line_number":118,"context_line":"   schema from tick-tick. This includes data migrations which need to"},{"line_number":119,"context_line":"   do work in tick releases, and while they may do work in tock"},{"line_number":120,"context_line":"   releases, the work done in tock releases cannot be"},{"line_number":121,"context_line":"   *mandatory*. This can be solved by requiring operators to"},{"line_number":122,"context_line":"   (force-)complete data migrations on a source tick before upgrading"},{"line_number":123,"context_line":"   to a target tick, for example."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"Example sequence"},{"line_number":126,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"011b6f18_ec5ce0af","line":123,"range":{"start_line":121,"start_character":16,"end_line":123,"end_character":33},"updated":"2022-02-21 18:15:18.000000000","message":"Like you mentioned this was always the case.  My main concern was the coding side of things, which you also added.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"change_message_id":"6502b08559767f3b79adb3df8bffa85873353a10","unresolved":true,"context_lines":[{"line_number":120,"context_line":"   releases, the work done in tock releases cannot be"},{"line_number":121,"context_line":"   *mandatory*. This can be solved by requiring operators to"},{"line_number":122,"context_line":"   (force-)complete data migrations on a source tick before upgrading"},{"line_number":123,"context_line":"   to a target tick, for example."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"Example sequence"},{"line_number":126,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5c6356be_06acd1c9","line":123,"in_reply_to":"0c3d03fa_5bb2765b","updated":"2022-02-25 20:46:49.000000000","message":"That\u0027s a good point. I\u0027m fine to RV+1 this regardless. Let\u0027s fix as an amendment. It seems it was generally understood well so I\u0027m not worried.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"change_message_id":"4687fddf70b0da06f25b7e4a02c761faba9d9fc9","unresolved":true,"context_lines":[{"line_number":120,"context_line":"   releases, the work done in tock releases cannot be"},{"line_number":121,"context_line":"   *mandatory*. This can be solved by requiring operators to"},{"line_number":122,"context_line":"   (force-)complete data migrations on a source tick before upgrading"},{"line_number":123,"context_line":"   to a target tick, for example."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"Example sequence"},{"line_number":126,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"84f1e366_760d4d93","line":123,"in_reply_to":"338fff81_88ed7cd0","updated":"2022-02-25 18:16:28.000000000","message":"Ok, thanks for the writeup, I understand it even better now and suggest we simply add \", as it is done today for upgrades between major versions.\"","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ae24ced66b09536974e2a6e5f778be66bae235dc","unresolved":true,"context_lines":[{"line_number":120,"context_line":"   releases, the work done in tock releases cannot be"},{"line_number":121,"context_line":"   *mandatory*. This can be solved by requiring operators to"},{"line_number":122,"context_line":"   (force-)complete data migrations on a source tick before upgrading"},{"line_number":123,"context_line":"   to a target tick, for example."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"Example sequence"},{"line_number":126,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"338fff81_88ed7cd0","line":123,"in_reply_to":"67771794_b34e42f4","updated":"2022-02-25 18:11:57.000000000","message":"Ack, perhaps just the wording here could change (if needed). It\u0027s not a new requirement, just noting how this has to be done in general.\n\nUsing nova as an example, already today when we do an online data migration, we generally have the code migrate things from an old format to a new format when they\u0027re touched. Meaning if we need to update the way we store an instance, if we read that instance, we save it back to the DB in the new format. Thus, these things get migrated at runtime as they\u0027re used. However, it\u0027s totally possible that a long-lived instance could be untouched for a year and thus never have had an opportunity to be opportunistically migrated in the DB. If we were to then remove code that allows for the old format, we\u0027d be in trouble. As such, we also generally provide tooling that will run through and \"touch\" everything in the DB to make sure it gets that opportunity, either manually-executed by the operator, or some very slow background task that attempts to do it automatically.\n\nThat\u0027s already how it works today, and is required for anyone trying to do this sort of thing where they want to deprecate the older schema/format and ultimately remove the code that provides that compatibility. So the point of this bullet, as added at the request of Gorka for clarity, is just that anyone doing this sort of thing in a tock release would need to make sure that operators have run that manual process before upgrading from tick to another tick, if the tock release is where they drop that support. It\u0027s the same as it is today, but with the assumption that nobody can possibly skip those releases anyway. For people doing FFUs, they often have to either run each intermediate release for a period of time to allow those migrations to happen, or run the manual tooling from those releases before moving to the next step. Eliminating that requirement (only for tock releases) is a major benefit to those people, and all it requires for the projects is to know that they can\u0027t introduce some migration process only in a tock release, which could be skipped by people.\n\nThat\u0027s a lot of words, but hopefully it makes sense. I think to anyone who currently orchestrates this sort of thing, it does, and as Gorka noted, he just wanted it to be called out specifically.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"44309f4884a1caaa89d5fb2544ffe51d3246bf92","unresolved":true,"context_lines":[{"line_number":120,"context_line":"   releases, the work done in tock releases cannot be"},{"line_number":121,"context_line":"   *mandatory*. This can be solved by requiring operators to"},{"line_number":122,"context_line":"   (force-)complete data migrations on a source tick before upgrading"},{"line_number":123,"context_line":"   to a target tick, for example."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"Example sequence"},{"line_number":126,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"0c3d03fa_5bb2765b","line":123,"in_reply_to":"84f1e366_760d4d93","updated":"2022-02-25 18:48:47.000000000","message":"Sure, sounds good. We\u0027ve got a bunch of RC+1 votes on this and it\u0027s due for approval on Monday. Would it be okay to queue up that amendment (and the important nit you have on the first line) after this to avoid setting us back? If you think it\u0027s important to get it in the first rev, I\u0027ll revise it directly and hope we can get the current voters to circle back quickly.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3fc3d59d8c643572ddf23f01c19fcf51d7b391f6","unresolved":true,"context_lines":[{"line_number":120,"context_line":"   releases, the work done in tock releases cannot be"},{"line_number":121,"context_line":"   *mandatory*. This can be solved by requiring operators to"},{"line_number":122,"context_line":"   (force-)complete data migrations on a source tick before upgrading"},{"line_number":123,"context_line":"   to a target tick, for example."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"Example sequence"},{"line_number":126,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"d4ce1963_94950d03","line":123,"in_reply_to":"b3b79cde_a0778198","updated":"2022-02-25 16:44:16.000000000","message":"I\u0027m not sure what you mean here?\n\nCurrent online data migrations *already* require tooling to ensure that untouched data is migrated. Either a periodic that makes sure it happens automatically at runtime, or tooling that handles it out-of-band. Nothing in this proposal changes that, only when that tooling could be removed after deprecation.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"},{"author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"change_message_id":"5dfd04280e51415a9ea11e5f753f12e56f20e7e2","unresolved":true,"context_lines":[{"line_number":120,"context_line":"   releases, the work done in tock releases cannot be"},{"line_number":121,"context_line":"   *mandatory*. This can be solved by requiring operators to"},{"line_number":122,"context_line":"   (force-)complete data migrations on a source tick before upgrading"},{"line_number":123,"context_line":"   to a target tick, for example."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"Example sequence"},{"line_number":126,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"67771794_b34e42f4","line":123,"in_reply_to":"d4ce1963_94950d03","updated":"2022-02-25 16:50:40.000000000","message":"Well, I\u0027m about this \"this can be solved\" part - I read it as a proposal to put extra work on operators / deployment projects, not preserving the current status quo. Deprecations are discussed 3 bullets above. That part I understand and am in love with it. This part confuses me.","commit_id":"f498019cf78a81d55d51bdcd5d0afc2f82c5e978"}]}