)]}'
{"nova/objects/instance_numa.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4ea50c164c24fbac401c1268ed0d016561b33cdd","unresolved":true,"context_lines":[{"line_number":96,"context_line":"            primitive.pop(\u0027cpu_policy\u0027, None)"},{"line_number":97,"context_line":"            primitive.pop(\u0027cpu_thread_policy\u0027, None)"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"    def obj_to_current_version(self):"},{"line_number":100,"context_line":"        updated \u003d False"},{"line_number":101,"context_line":"        version \u003d versionutils.convert_version_to_tuple(self.VERSION)"},{"line_number":102,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"0bd7d99e_6589861d","line":99,"updated":"2025-02-07 15:27:47.000000000","message":"+1 for renaming. I worry this name makes it look like this is part of o.vo itself and people might be thinking there\u0027s either (a) more infrastructure (i.e. magic) around it or (b) they can use it elsewhere. Since (a) is not a thing I think actually putting this on the base object is probably not the best plan, but I\u0027m not sure. Is that your intent? Or just keep it here in this object?","commit_id":"b0336fbc6f85fdaf1bf212ccf2d5182dd647c8cc"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"5485cfcf5b6d27920a565b9599a8637903d09ce8","unresolved":true,"context_lines":[{"line_number":96,"context_line":"            primitive.pop(\u0027cpu_policy\u0027, None)"},{"line_number":97,"context_line":"            primitive.pop(\u0027cpu_thread_policy\u0027, None)"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"    def obj_to_current_version(self):"},{"line_number":100,"context_line":"        updated \u003d False"},{"line_number":101,"context_line":"        version \u003d versionutils.convert_version_to_tuple(self.VERSION)"},{"line_number":102,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"b0dddda0_a67fda9f","line":99,"in_reply_to":"0bd7d99e_6589861d","updated":"2025-02-10 11:11:43.000000000","message":"I\u0027m actually torn between these options as I\u0027m not sure how common the need to forward port an object data. So far I haven\u0027t really seen similar in other objects.  But probably I will discover them when I add the generic testing https://review.opendev.org/c/openstack/nova/+/940984 to our json blob objects. \n\nI already see one reason to make this eventually part of the base interface. Even in the current patch the InstanceNUMATopology object is the one that gets the trigger of forward porting, but that object needs to forward port every embedded sub objects like InstanceNUMACell. So if the generic need is to be able to forward port an object, just generic need can only be fulfulled if all the embedded sub object provides a way to forward port them.","commit_id":"b0336fbc6f85fdaf1bf212ccf2d5182dd647c8cc"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f474ab21c8dfff7a8616c824151af5d39c8f62f8","unresolved":true,"context_lines":[{"line_number":96,"context_line":"            primitive.pop(\u0027cpu_policy\u0027, None)"},{"line_number":97,"context_line":"            primitive.pop(\u0027cpu_thread_policy\u0027, None)"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"    def obj_to_current_version(self):"},{"line_number":100,"context_line":"        updated \u003d False"},{"line_number":101,"context_line":"        version \u003d versionutils.convert_version_to_tuple(self.VERSION)"},{"line_number":102,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"d087de0c_768d32d3","line":99,"in_reply_to":"3e478bf6_e0c2f57b","updated":"2025-02-10 15:30:17.000000000","message":"\u003e dan im not sure what the best way forward is, i can asy that i at least had the same expectionat that we shoudl always expect to work with the latest version fo the object supported by the current code on the comptue nodes.\n\u003e\n\u003e all the numa code (cpu pinning, hugpages, pci/sriov) is written with taht expectation\n\nYeah, I get that the code expects that, and I can certainly see how one might have assumed there was magic making this happen, but it\u0027s just not the case.\n\n\u003e we do not pass the isntance_numa object between compute nodes in a way where this would matter.\n\nI also get that much of your response is about this specific case and the *current* set of assumptions we have about which nodes get *this* object from which other nodes. My point about whether or not to make this part of the base infrastructure or not is concerning whether we can or should make those assumptions everywhere, and of course, whether that should be something that is pushed on everyone else. Most of the projects that use o.vo don\u0027t have a conductor that can always backlevel things for them, which means they *definitely* have no reasonable assumption that the version any one node receives is anything other than exactly the version supported by the sending node. If you add a method that implies that an object can always be magically forward-ported, you further entrench the (currently-incorrect) mindset that the developer can just ignore the versions of the objects and assume they\u0027ve got a current version always. In that case, the semantics of the version number might as well just be dropped and we can let any amount of incompatible change between objects happen since you can just convert between any version, old or new.\n\nEven in Nova where we do have a conductor, unless you\u0027re going to start bouncing objects to the conductor for forward-leveling as well (which I think would be a bad idea), you\u0027ll always have the inter-compute version issue breaking the assumption of \"always current.\" It\u0027s also definitely not always possible to forward-port an object as most if our back-level operations just delete data from the object, unlike this one where we *move* data.\n\nI think this was a specific situation where the author(s) of this numa code made some unfortunate assumptions about how things work, and we can fix those things. I don\u0027t think that means we should try to force all the other objects to always support back-leveling and forward-porting, nor try to codify the (incorrect) assumption this code was making when the rest of it was not. The fact that this went almost totally unnoticed for so long, and requires a series of grey-area events to trigger tells me that we were 99% correct and this one just slipped through the cracks. It happens.","commit_id":"b0336fbc6f85fdaf1bf212ccf2d5182dd647c8cc"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1e7c56739433ba1aaf312a51e57deda928c8b1fa","unresolved":true,"context_lines":[{"line_number":96,"context_line":"            primitive.pop(\u0027cpu_policy\u0027, None)"},{"line_number":97,"context_line":"            primitive.pop(\u0027cpu_thread_policy\u0027, None)"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"    def obj_to_current_version(self):"},{"line_number":100,"context_line":"        updated \u003d False"},{"line_number":101,"context_line":"        version \u003d versionutils.convert_version_to_tuple(self.VERSION)"},{"line_number":102,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"3e478bf6_e0c2f57b","line":99,"in_reply_to":"b0dddda0_a67fda9f","updated":"2025-02-10 12:02:21.000000000","message":"dan im not sure what the best way forward is, i can asy that i at least had the same expectionat that we shoudl always expect to work with the latest version fo the object supported by the current code on the comptue nodes.\n\nall the numa code (cpu pinning, hugpages, pci/sriov) is written with taht expectation \n\nyou may not have been aware that was how we used the objects but that is how the code has been written for 8+ years.\n\nwe do not pass the isntance_numa object between compute nodes in a way where this would matter.\n\nfor live migration we have dedicated filed in the migration_data object ot used to update the xml. for resize/cold migration/unshleve/evacuate we generate a new instance numa object on the destination node we do not pass it between nodes becasue the data is normally different on each host.\nrebuild does not change host but is also not allowed modify the numa topology.\n\nwe require that the conductor,api,schdler, metadata api and console proxies are all upgraded together before the comptue nodes.\n\nthe compute nodes can have rpc calls between them but we expect to recive the object in the max version we supprot.\nnow the reply case is interesting as the reply will be in the newest verion the the remote node supprots which coudl be older then we supprot however we dont pass back instance objects in the reply, at least not for live migraton,\n\nwe pass back the live migraiton data object and for those we explcity handel checkign for older verions.\n\n\nthe instance numa obejct has 2 parts\n\nits used to carry the requested numa toplogy but also the pinning.\nwhen we are moving between hosts its only the former part that is shared (and that can be consucted from the falvor/image so im not sure that even used form teh instance object in the cold migration case. for resize the request can change to it can use the one form the instance object and it need to constuct it form the flavor so i woudl guess we just alwasy constuct it form the flavor/image since resize and coldmigrration share the same code.\n\nso i get general concern but i dont think it applies in this case.","commit_id":"b0336fbc6f85fdaf1bf212ccf2d5182dd647c8cc"}]}