)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7dd2164a4d686e491bbbad70e8a2084fa8a14732","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"fe354548_9b8e6b29","updated":"2024-06-20 18:36:13.000000000","message":"this is not somethn we can block at the api level.\n\nwhiel this may not be valid in your case this is entirly valid in general\n\ni.e. resizing from one host aggate to another","commit_id":"a3ceb3825c80d347ea58563d811906001259757e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e9cdfef4de25e3fee3f10bea3cd283eaabec9c67","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6cfb0772_353e1bd4","in_reply_to":"26419cf4_cf2a9886","updated":"2024-06-20 20:27:49.000000000","message":"one of the problems with this patch is that end user intentally have no visablity into hostaggares or what host there workload is on so they cannot mane an informed descisoin as to waht flavor they can resize too\n\nsome public cloud also do not show the flavor extra spec at all to normal users.\n\nso the current patch would lead to interup issues and undisagnoable failure to resize form a normal user prespective.\n\nno data loss happen becuase the reslzie form local to ceph stroage causes\nthe resize to fail when entering resize_Verify and you simply need to revert the reisze.\n\na run time evaulated ops feild is even more of a breaking api change and i think is more unaccapbel then the current patch.\n\nif you want to prevent this today it woudl be possibe for you to create custom filter that will detect your downstream flavor families and reject and raise a excction causing the resize to fail at the schduler point before we actully resize.\n\n\nin the future we could add standard trait for local/network storage and recored what type of storage backend an isntance is booted on. with that we could then extend nova to be able to schdule based on taht and prevent resizes betwen \nstorage backends.\n\nthat is a future feture we have disucssed in the past but it is not one we have had time to impement to date.\n\ni would prefer if that was the approach we took to enable this usecase.\n\n\ni dont think this is valid to treat as a bugfix and backprot.\nif we were to do anytig in a bug fix it woud lhave to be contoled by a new config option and disabeld by default.\n\nthis has two high a potentil to break existing valid workflows to enable by default.","commit_id":"a3ceb3825c80d347ea58563d811906001259757e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"30d11366f11016cca9c01a80569736785b4ede5e","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"faace15e_e0f62659","in_reply_to":"272a5568_cf4aaec8","updated":"2024-06-20 20:00:34.000000000","message":"no you have misunderstood https://bugs.launchpad.net/nova/+bug/1803331 and how that was orginal traiged.\n\nwhile migration between diffent storage backend is unsupproted via rezie or any other method it entrily valid to rezise between diffent falvor and to move intsnace btween Aviabality zone, cells (if corss cell resize is enabled) or host aggreates.\n\n\ni proably shoudl have triage it as wishlist as it actully a feature request not a valid bug.\n\ni set it to high as initally we beiveld there was data loss but that was nto the case as far as i am aware so i should proably drop it form high.\n\nthis was really operator error in how they configured nova.\n\ntoday the safest way to mix is ot use\nhttps://docs.openstack.org/nova/latest/reference/isolate-aggregates.html\n\nif you don\u0027t an you try to use something like the aggregate instance extra specs\nfilter then you are required to ensure that every flavor has a custom extra spec for the backend and every host is a host aggarte that filters on that extra spec.\n\n\nthe isolated aggrates feature is much less error prone which is why re recommend using it when ever this come up.","commit_id":"a3ceb3825c80d347ea58563d811906001259757e"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"fdeacd3ddeda482d0ccbfacd004faa7e801fe431","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"a3a013d9_b174d36a","in_reply_to":"6cfb0772_353e1bd4","updated":"2024-06-20 20:33:45.000000000","message":"I think that it is fine to have a configuration that the operator/administrators of the cloud can change at their will. I can do that if you prefer. \n\nLet me know, if you like that, then I can even do both, have a configuration to enable this feature (the default would be false for the feature), and then either work as is here now, or have an ops (expression) that is defined by the operator and evaluated in runtime.","commit_id":"a3ceb3825c80d347ea58563d811906001259757e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8ba62b98c7d74ce58938afd1a57b3cea0d6827c7","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"e1c82fa4_a1543d99","in_reply_to":"a3a013d9_b174d36a","updated":"2024-06-20 21:45:58.000000000","message":"honestly both the config option and the runtime evaualted expresshiosn are not suitable approches in my view and would not be appropate to do upstream.\n\nwe very strongly dislike config driven api behaivor and i dont thinkthere is any apatie to allow arbity excution of expressiosn defiend in flavor extra spec so i would be -1 on the config option and -2 on the expression.","commit_id":"a3ceb3825c80d347ea58563d811906001259757e"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"6bcb90f2097d3a6d392f1081f6980e4743f9ba06","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"26419cf4_cf2a9886","in_reply_to":"faace15e_e0f62659","updated":"2024-06-20 20:06:51.000000000","message":"I see. And, let\u0027s say we want to have some Nova hosts with local disks as storage backend, and some other Nova hosts to have Ceph as the backend for Nova disks. Then, if we have flavor family \"C\" for the VMs that will have Nova disks on Ceph, and \"L\" that will have disks on local NVME drivers. \n\nThen, if I want to change from a VM with an L flavor to C flavor, that will cause data loss, as the resize workflow will actually create a new disk in the host where L flavors are applied. The same happens the other way around. \n\nThat is also another reason why we are suggesting this patch.\n\nWhat if we added an option in the flavor, such as an \"ops\" field, where we can have an expression that is evaluated in runtime, and then the operator can customize from which flavor, and to which flavors the VM can be resized safely.","commit_id":"a3ceb3825c80d347ea58563d811906001259757e"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"55a7e5c007bbd07df3ab25662989c243c0b1b1e2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"272a5568_cf4aaec8","in_reply_to":"fe354548_9b8e6b29","updated":"2024-06-20 18:42:00.000000000","message":"I understand that. However, Nova is not prepared for this, right? I mean, the situation reported in [1] is one that does not work. Therefore, it made sense to block such cases.\n\nWhat if we create a property to allow or not such resize between flavor families? Then, it is up to operators.","commit_id":"a3ceb3825c80d347ea58563d811906001259757e"}]}