)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1a8156fdd63c5806f5dc851184f854ce9f2029b5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"6a1219ec_05a8a395","updated":"2023-02-28 08:22:44.000000000","message":"Looks OK. I will upgrade to +2 once the TODO in the commit message is resolved","commit_id":"6604df5c84753c0a48c01d98ffd3991a15810cfc"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5e72efd22ae2761602817818174b557852689df9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"f011883b_945d1010","updated":"2023-03-03 16:17:54.000000000","message":"We should probably take this conversation to somewhere other than the release notes patch here. Obviously if Dmitriy sees this as a concern, we may expect other people to have the same reaction.","commit_id":"f587685f601bd15c1820c23086c3c68274949d5f"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"e12ca8302d741a08588438493e08b3188055dade","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"8130cd68_92b9592d","updated":"2023-03-02 18:18:17.000000000","message":"this lgtm, thanks","commit_id":"f587685f601bd15c1820c23086c3c68274949d5f"}],"releasenotes/notes/antelope-prelude-4a99907b00e739f8.yaml":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"09f15bcdf649949d08b6b95457374c9528298968","unresolved":true,"context_lines":[{"line_number":3,"context_line":"    The OpenStack 2023.1 (Nova 27.0.0) release includes many new features and"},{"line_number":4,"context_line":"    bug fixes. Please be sure to read the upgrade section which describes the"},{"line_number":5,"context_line":"    required actions to upgrade your cloud from 26.0.0 (Zed) to 27.0.0 (2023.1)."},{"line_number":6,"context_line":"    As a reminder, OpenStack 2023.1 is a `SLURP release`__."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"    .. __: https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html"},{"line_number":9,"context_line":""}],"source_content_type":"text/x-yaml","patch_set":2,"id":"16ad1d25_aacc99fd","line":6,"updated":"2023-02-28 10:06:09.000000000","message":"I would say it is the first SLURP release. So this will be the base release of the first supported skip level upgrade from 2023.1 to 2024.1","commit_id":"e7dcded82a64f16e0036ff467e92fef21380e790"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"76bcfd4e0054dcd5908f99dfa80649a14bff36cf","unresolved":true,"context_lines":[{"line_number":3,"context_line":"    The OpenStack 2023.1 (Nova 27.0.0) release includes many new features and"},{"line_number":4,"context_line":"    bug fixes. Please be sure to read the upgrade section which describes the"},{"line_number":5,"context_line":"    required actions to upgrade your cloud from 26.0.0 (Zed) to 27.0.0 (2023.1)."},{"line_number":6,"context_line":"    As a reminder, OpenStack 2023.1 is a `SLURP release`__."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"    .. __: https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html"},{"line_number":9,"context_line":""}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3eb42c96_4c246858","line":6,"in_reply_to":"16ad1d25_aacc99fd","updated":"2023-02-28 10:15:24.000000000","message":"firstly i woudl avoid saying SLURP release\n\nSLURP is skip level upgrade release process \n\n\nSLURP release is\n\nskip level upgrade release process release\n\n\ni would use \"skip level upgrade release\"\n\nor SLU release\n\n\nsecondly the first skip level upgrade release is actuly 2024.1\n2023.1 is the first base release for a skip level upgrade.\nbut the first release to supprot skip level upgrade is 2024.1\n\nso its incorrect to say that 2023.1 is a skip level upgrade release.","commit_id":"e7dcded82a64f16e0036ff467e92fef21380e790"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"8a160786d5179fce20118ec1759fa4dd6f5deabf","unresolved":false,"context_lines":[{"line_number":3,"context_line":"    The OpenStack 2023.1 (Nova 27.0.0) release includes many new features and"},{"line_number":4,"context_line":"    bug fixes. Please be sure to read the upgrade section which describes the"},{"line_number":5,"context_line":"    required actions to upgrade your cloud from 26.0.0 (Zed) to 27.0.0 (2023.1)."},{"line_number":6,"context_line":"    As a reminder, OpenStack 2023.1 is a `SLURP release`__."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"    .. __: https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html"},{"line_number":9,"context_line":""}],"source_content_type":"text/x-yaml","patch_set":2,"id":"dde0206a_4135d064","line":6,"in_reply_to":"3eb42c96_4c246858","updated":"2023-03-01 09:27:33.000000000","message":"Ack","commit_id":"e7dcded82a64f16e0036ff467e92fef21380e790"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d4a1ecb637bd210edd4043847cb23dfc8230418b","unresolved":true,"context_lines":[{"line_number":6,"context_line":"    As a reminder, OpenStack 2023.1 is our first `Skip-Level-Upgrade Release`__"},{"line_number":7,"context_line":"    (starting from now, we name it a `SLURP release`) where you can"},{"line_number":8,"context_line":"    rolling-upgrade your compute services from OpenStack Yoga as an experimental"},{"line_number":9,"context_line":"    feature. Next SLURP release will be 2024.1."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"    .. __: https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html"},{"line_number":12,"context_line":""}],"source_content_type":"text/x-yaml","patch_set":3,"id":"591e8e5d_3d382627","line":9,"updated":"2023-03-02 15:17:16.000000000","message":"FWIW, this seems totally clear to me. Not all projects will support yoga as an experimental upgrade source, but nova will, and we call it out here.","commit_id":"f587685f601bd15c1820c23086c3c68274949d5f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d4a1ecb637bd210edd4043847cb23dfc8230418b","unresolved":true,"context_lines":[{"line_number":34,"context_line":"      This stored UUID will be considered the source of truth for knowing whether"},{"line_number":35,"context_line":"      the compute service hostame has been modified or not. As a reminder,"},{"line_number":36,"context_line":"      changing a compute hostname is forbidden, particularly when this compute is"},{"line_number":37,"context_line":"      currently running instances on top of it."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"    - `SPICE consoles \u003chttps://docs.openstack.org/nova/latest/admin/remote-console-access.html#spice-console\u003e`_"},{"line_number":40,"context_line":"      can now be configured with compression settings which include choices of the"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"8a82cda6_5019e5fa","line":37,"updated":"2023-03-02 15:17:16.000000000","message":"I would say \"particularly when a compute has instances running on it\", but don\u0027t change it unless you respin for something else.","commit_id":"f587685f601bd15c1820c23086c3c68274949d5f"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"993783271ffaac06ec2f59f5745602e4e15f461d","unresolved":true,"context_lines":[{"line_number":42,"context_line":""},{"line_number":43,"context_line":"    - Fully-Qualified Domain Names are now considered valid for an instance"},{"line_number":44,"context_line":"      hostname if you use the 2.94 API microversion."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"    - By opting into 2.95 API microversion, evacuated instances will remain"},{"line_number":47,"context_line":"      stopped on the destination host until manually started."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"    - Nova APIs now `by default support new RBAC policies \u003chttps://docs.openstack.org/nova/latest/configuration/policy.html\u003e`"},{"line_number":50,"context_line":"      and scopes. See our `Policy Concepts documention \u003chttps://docs.openstack.org/nova/latest/configuration/policy-concepts.html\u003e`"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"47db7b12_f9b82483","line":47,"range":{"start_line":45,"start_character":0,"end_line":47,"end_character":61},"updated":"2023-03-01 16:05:13.000000000","message":"Um, is there a default way then to get information about instances that were started on previous host? Or how you as operator should know what to start and what not?\n\nAs from operator perspective intention of evacuate is to restore functionality of VMs ASAP. So perfect option is to start what was started and leave stopped what was !\u003d ACTIVE, except cases with encrypted volumes/memory/etc. OR, having a decent way to see what should be started.\n\nI assume this change will also effect projects like masakari...","commit_id":"f587685f601bd15c1820c23086c3c68274949d5f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d932d526cc50d0bad3765635d1037f6f4c10d45a","unresolved":true,"context_lines":[{"line_number":42,"context_line":""},{"line_number":43,"context_line":"    - Fully-Qualified Domain Names are now considered valid for an instance"},{"line_number":44,"context_line":"      hostname if you use the 2.94 API microversion."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"    - By opting into 2.95 API microversion, evacuated instances will remain"},{"line_number":47,"context_line":"      stopped on the destination host until manually started."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"    - Nova APIs now `by default support new RBAC policies \u003chttps://docs.openstack.org/nova/latest/configuration/policy.html\u003e`"},{"line_number":50,"context_line":"      and scopes. See our `Policy Concepts documention \u003chttps://docs.openstack.org/nova/latest/configuration/policy-concepts.html\u003e`"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"f95829f8_ca20be51","line":47,"range":{"start_line":45,"start_character":0,"end_line":47,"end_character":61},"in_reply_to":"47db7b12_f9b82483","updated":"2023-03-02 09:38:18.000000000","message":"You can use older microversion to keep the old behavior.\n\nI assume both masakari or the admin doing the evacuation can read the state of the instance before start the evacuation then it can decide based on that and external policy to restart the VM on the target or not.","commit_id":"f587685f601bd15c1820c23086c3c68274949d5f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5e72efd22ae2761602817818174b557852689df9","unresolved":true,"context_lines":[{"line_number":42,"context_line":""},{"line_number":43,"context_line":"    - Fully-Qualified Domain Names are now considered valid for an instance"},{"line_number":44,"context_line":"      hostname if you use the 2.94 API microversion."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"    - By opting into 2.95 API microversion, evacuated instances will remain"},{"line_number":47,"context_line":"      stopped on the destination host until manually started."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"    - Nova APIs now `by default support new RBAC policies \u003chttps://docs.openstack.org/nova/latest/configuration/policy.html\u003e`"},{"line_number":50,"context_line":"      and scopes. See our `Policy Concepts documention \u003chttps://docs.openstack.org/nova/latest/configuration/policy-concepts.html\u003e`"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"26ef0906_9ad07877","line":47,"range":{"start_line":45,"start_character":0,"end_line":47,"end_character":61},"in_reply_to":"4df6a519_54f12764","updated":"2023-03-03 16:17:54.000000000","message":"\u003e What I was saying is, that operator should have tools at very least to start VMs after evacuation and that data resides in Nova. As once you\u0027ve pushed evacuate button - there\u0027s kind of no way of saying what you should start now.\n\nWell, to be clear, the data that resides in nova is \"was it running before the failure.\" Nova doesn\u0027t know if it\u0027s running \"now\", which is why we don\u0027t change the state of the instance once we lose contact with the compute node (very explicitly).\n\n\u003e Of course I can write a wrapper that will fetch list of instances from host, execute evacuation and then iterate over received list to restore state, but that is totally degradation of usability from operator perspective. Alike replacing reporting used resources from hypervisors with placement without providing any api for auditing them. So now instead of 1 request to nova it\u0027s required to make *hosts requests to placement which is significantly slower and cause unneeded load, especially if you want to gather such data regularly.\n\nI\u0027m a bit confused here. To evacuate all the instances on a host, you already had to write half of that script, right? Are you perhaps conflating the server-side `evacuate` operation (which is per-instance) with the deprecated (or soon to be) novaclient `host-evacuate` operation which hits that button for each instance on a given host?\n\n\u003e I\u0027m not sure what you meant Dan about `accessing the data of the broken one`? Volume multi-attach? As I\u0027m not aware of ways how you can do that- you can\u0027t detach root volume, you can\u0027t create new instance with the same root/ephemeral volume. If you use volume multi-attach - it\u0027s not brightest idea at the first place and if you do - you should be ready for such situations to happen.\n\nNo, I mean any shared state. Could be in a volume, or some other service, etc.\n\nLet\u0027s say I have an instance that is responsible for connecting to a database and incrementing an integer \"clock\". I run exactly one of those instances and it provides the monotonic and atomic service for everything else. Then the compute node it\u0027s running on goes down. My application detects this and spins up another instance to resume providing the clock service. Then the operator comes along and evacuates the original clock instance to another node and now there are two running. The operator didn\u0027t know the nature of what was in the original instance and that it really shouldn\u0027t be restarted without special handling.\n\nThis is obviously a contrived example, and in a lot of cases, people *would* want their instance restarted after evacuation for sure. The point here was that choosing one behavior will be always \"wrong\" for some people and \"evacuate to off\" is more universally applicable than \"evacuate to on\" (for the encrypted volume reason).","commit_id":"f587685f601bd15c1820c23086c3c68274949d5f"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"12bb354fdcdb7fcc8aa6f568084f88e76e833b7f","unresolved":true,"context_lines":[{"line_number":42,"context_line":""},{"line_number":43,"context_line":"    - Fully-Qualified Domain Names are now considered valid for an instance"},{"line_number":44,"context_line":"      hostname if you use the 2.94 API microversion."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"    - By opting into 2.95 API microversion, evacuated instances will remain"},{"line_number":47,"context_line":"      stopped on the destination host until manually started."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"    - Nova APIs now `by default support new RBAC policies \u003chttps://docs.openstack.org/nova/latest/configuration/policy.html\u003e`"},{"line_number":50,"context_line":"      and scopes. See our `Policy Concepts documention \u003chttps://docs.openstack.org/nova/latest/configuration/policy-concepts.html\u003e`"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"4df6a519_54f12764","line":47,"range":{"start_line":45,"start_character":0,"end_line":47,"end_character":61},"in_reply_to":"c227dcd5_c44a525b","updated":"2023-03-03 15:37:20.000000000","message":"What I was saying is, that operator should have tools at very least to start VMs after evacuation and that data resides in Nova. As once you\u0027ve pushed evacuate button - there\u0027s kind of no way of saying what you should start now.\n\nOf course I can write a wrapper that will fetch list of instances from host, execute evacuation and then iterate over received list to restore state, but that is totally degradation of usability from operator perspective. Alike replacing reporting used resources from hypervisors with placement without providing any api for auditing them. So now instead of 1 request to nova it\u0027s required to make *hosts requests to placement which is significantly slower and cause unneeded load, especially if you want to gather such data regularly.\n\nEventually such small things cause ppl saying \"openstack is hard\", as we\u0027re not really making it easier for end users with such changes.\n\nI\u0027m not sure what you meant Dan about `accessing the data of the broken one`? Volume multi-attach? As I\u0027m not aware of ways how you can do that- you can\u0027t detach root volume, you can\u0027t create new instance with the same root/ephemeral volume. If you use volume multi-attach - it\u0027s not brightest idea at the first place and if you do - you should be ready for such situations to happen.","commit_id":"f587685f601bd15c1820c23086c3c68274949d5f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d4a1ecb637bd210edd4043847cb23dfc8230418b","unresolved":true,"context_lines":[{"line_number":42,"context_line":""},{"line_number":43,"context_line":"    - Fully-Qualified Domain Names are now considered valid for an instance"},{"line_number":44,"context_line":"      hostname if you use the 2.94 API microversion."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"    - By opting into 2.95 API microversion, evacuated instances will remain"},{"line_number":47,"context_line":"      stopped on the destination host until manually started."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"    - Nova APIs now `by default support new RBAC policies \u003chttps://docs.openstack.org/nova/latest/configuration/policy.html\u003e`"},{"line_number":50,"context_line":"      and scopes. See our `Policy Concepts documention \u003chttps://docs.openstack.org/nova/latest/configuration/policy-concepts.html\u003e`"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"c227dcd5_c44a525b","line":47,"range":{"start_line":45,"start_character":0,"end_line":47,"end_character":61},"in_reply_to":"f95829f8_ca20be51","updated":"2023-03-02 15:17:16.000000000","message":"Another point - when you\u0027re going to evacuate an instance, you don\u0027t know if it\u0027s running or not. It may say ACTIVE, but that\u0027s just Nova\u0027s last-known state. It may be up or down in reality, and without strict fencing, it may still be accessing shared storage or doing other things. If it\u0027s fenced, the actual owner/user may have already recreated the instance elsewhere, doing the job and accessing the data of the broken one. If an operator evacuates that instance to a running state elsewhere, they may actually cause *more* trouble.\n\nAs gibi said, if the operator wants to take that risk, they can power it on after it has been evacuated.","commit_id":"f587685f601bd15c1820c23086c3c68274949d5f"}]}