| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-26 | |||
| 17:52:01 | adrianc | sean-k-mooney: without it the port will be down and no MAC will be allocated to the VF, ill push it as POC code for neutron | |
| 17:52:06 | sean-k-mooney | adrianc: i normally dont have meeting on tuesday so it the day i set aside to test complicated stuff end to end so i am happy to pull in all the changes you have and try an replicate it locally | |
| 17:52:49 | sean-k-mooney | adrianc: you should still have a mac at least in the libvirt xml | |
| 17:53:31 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Use long_rpc_timeout in select_destinations RPC call https://review.openstack.org/620121 | |
| 17:53:41 | sean-k-mooney | adrianc: without the neutron change the only stuff that wont work is the operation preferment by the sriovnic agent | |
| 17:53:55 | sean-k-mooney | the vf mac is set by nova in the libvirt xml | |
| 17:54:39 | sean-k-mooney | that is based on the neutron port and should not be effect by the ports bindings or the port status | |
| 17:54:47 | adrianc | sean-k-mooney: yes, you are right, the issue is IIRC, the MAC on the source is not zeroed | |
| 17:55:02 | adrianc | did it a while back, but i remember it was needed :) | |
| 17:55:32 | sean-k-mooney | adrianc: ah when the vf is unbound it keeps the vm mac | |
| 17:55:41 | adrianc | ya | |
| 17:55:57 | sean-k-mooney | adrianc: that is assuming the vf is rebound to the kenel dirivce and does not stay bound to vfio-pci | |
| 17:56:08 | sean-k-mooney | sorry never mind | |
| 17:56:16 | sean-k-mooney | with macvtap its not bound to vfio-pci | |
| 17:57:16 | sean-k-mooney | ok well regarding you question on the spec https://review.openstack.org/#/c/605116/6/specs/stein/approved/libvirt-neutron-sriov-livemigration.rst@111 | |
| 17:57:34 | sean-k-mooney | i was leaning towords option 2 | |
| 17:57:48 | sean-k-mooney | using a new pci request with an new uuid | |
| 17:58:32 | sean-k-mooney | but i was hoping to avoid data model changes | |
| 17:59:27 | sean-k-mooney | ill keep both option in mind when looking at your code. | |
| 17:59:28 | adrianc | you will need to keep that request_id somewhere | |
| 18:00:04 | dansmith | mriedem: looks like artom answered questions and pushed up a tweak to this and you were +0.9 before.. can you circle back? https://review.openstack.org/#/c/599587/ | |
| 18:00:05 | sean-k-mooney | adrianc: i was wondering could we use a uuid5 that is derived from the host+vif port id | |
| 18:00:39 | mriedem | dansmith: yeah, was thinking about it in my mental queue earlier | |
| 18:00:49 | dansmith | mriedem: ack, thanks | |
| 18:01:04 | dansmith | bauzas: I assume you're going to be the +W on that? | |
| 18:02:52 | adrianc | sean-k-mooney: imposing a certain logic on the uuid creation doesnt sound like something that will fly, is there a precedence in nova ? | |
| 18:03:24 | bauzas | dansmith: mriedem: sorry folks, was on some internal issue | |
| 18:03:47 | sean-k-mooney | adrianc: neutron are using uuid5's for generating the placemnet uuids for bandwith awere scheduling. | |
| 18:03:55 | bauzas | dansmith: and yeah, i was about looking at https://review.openstack.org/#/c/599587/ | |
| 18:04:04 | sean-k-mooney | adrianc: i dont know of a precedent in nova for doing the same | |
| 18:04:09 | bauzas | mriedem: for the functional test, I didn't have time yet | |
| 18:04:49 | sean-k-mooney | adrianc: but even if we did not generate the deterministaclly we could put the pci request id in the migration data we pass back | |
| 18:07:25 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Default zero disk flavor to RULE_ADMIN_API in Stein https://review.openstack.org/603910 | |
| 18:08:44 | adrianc | sean-k-mooney: so we extend the LiveMigrateData object, using the same request makes sense as in a way its the same request claimed on a different host. downside is that you have a point in time where you will have a PCI device allocated on the source host and a PCI device claimed on the destination host for the same request ID | |
| 18:09:26 | sean-k-mooney | adrianc: this may be a good usecase for a uuid5 however. https://docs.python.org/2/library/uuid.html#uuid.uuid5 the namespace uuid would be the neutron port uuid and the name would be the hostname. the adress space of UUIDs should be sufficent such that a colision is very unlikely. | |
| 18:09:58 | sean-k-mooney | adrianc: using the same request id would also work as long as we can clean up | |
| 18:10:26 | sean-k-mooney | adrianc: if we could avoid relying on the periodic task that would be better | |
| 18:10:49 | sean-k-mooney | adrianc: could we remove the source claim in post migrate | |
| 18:11:48 | artom | dansmith, oh hey, thanks for pushing that :) | |
| 18:14:45 | adrianc | sean-k-mooney: lemme check, p.s https://review.openstack.org/#/c/620123/1 | |
| 18:17:16 | mriedem | and returns to conductor | |
| 18:17:16 | mriedem | the claim happens on the dest before live migration starts | |
| 18:17:16 | mriedem | i think you're understimating the claim issue | |
| 18:17:16 | mriedem | artom: replies on the previous PS fwiw | |
| 18:17:30 | mriedem | but it's the source that will need to orchestrate what happens with the claim after a successful or failed live migration | |
| 18:18:41 | mriedem | maybe it's as simple as rt.drop_move_claim like you said | |
| 18:18:50 | sean-k-mooney | mriedem: artom for what its worth we will have to do the exact same claims dance for the sriov migration as well. the main difference being one is in the pci code and the other is in the numa code | |
| 18:19:07 | mriedem | the claims dance is one of my most hated dances | |
| 18:19:13 | mriedem | right up there with line dancing | |
| 18:19:26 | artom | There are dances you like? | |
| 18:19:33 | mriedem | dude | |
| 18:19:33 | sean-k-mooney | and river dacne if you an irish person | |
| 18:19:36 | mriedem | THE HUMPTY DANCE | |
| 18:19:48 | artom | I... Have I been missing out? | |
| 18:19:55 | mriedem | dansmith: that reminds me, was it you that didn't get my humpty dance reference while we were strolling through the death camp? | |
| 18:20:17 | mriedem | https://www.youtube.com/watch?v=PBsjggc5jHM | |
| 18:20:50 | adrianc | sean-k-mooney: to which source claim are you referring ? | |
| 18:21:11 | dansmith | mriedem: I knew you were talking about this song, I just didn't get how it related to, uh, mass murder | |
| 18:21:28 | mriedem | i don't remember | |
| 18:22:57 | artom | mriedem, you can pass the host to drop_move_claim | |
| 18:22:59 | adrianc | sean-k-mooney: if you mean removing the free_instance_allocations() in _post_live_migration then yes, but it will be another place we rely on the periodic resource_tracker job | |
| 18:23:32 | artom | So even if we call it from the source, we could drop the claim on the... wait, if we call it on the source, we just drop the resources on the source, since the instance is on the dest | |
| 18:24:19 | adrianc | artom: Hi, in regards to numa aware live migration, the plan is to converge for stein right ? as the SRIOV live migration will not mean much without it | |
| 18:24:28 | sean-k-mooney | adrianc: in option 1 we would have 2 vfs calimed with the same pci request uuid so if we do that i was wondering if we can avaoid relying on the periodic heal and proactivly release the vf on the source when we then migration completes | |
| 18:24:56 | sean-k-mooney | adrianc: well the sriov migration should be doable without the numa one | |
| 18:25:18 | mriedem | artom: see | |
| 18:25:53 | adrianc | sean-k-mooney: in the PS i am freeing the instance allocation on the source node. | |
| 18:26:52 | sean-k-mooney | adrianc: i ok ill read what you are currently doing and then ill respond to the question on the spec or updated it to match what you have implmeneted | |
| 18:27:20 | adrianc | sean-k-mooney: unless you request dedicated CPUs right ? (previous comment) | |
| 18:28:20 | sean-k-mooney | adrianc: yes but wwe shoudl treat these as seperate specs and seperate work items but makes sure they both work togeter in the end | |
| 18:28:38 | artom | mriedem, wait, so the cell conductor isn't involved at all? It's just superconductor and the source and dest? | |
| 18:28:55 | sean-k-mooney | adrianc: in the simple case fo a floating instace with neutron sriov interface there is no numa affinity or numa topology for the guest | |
| 18:28:55 | adrianc | sean-k-mooney: i agree, they do not depend, i was just wondering if its planned for stein as well :) | |
| 18:29:33 | sean-k-mooney | adrianc: the numa aware migration is proably more impactful to land in stien then sriov but hopefully both can land | |
| 18:31:24 | mriedem | artom: yes | |
| 18:31:41 | mriedem | superconductor orchestrates everything to find the correct dest host, then kicks things off with an rpc cast to the source | |
| 18:31:50 | mriedem | and then source/dest computes just rpc back and forth | |
| 18:32:00 | artom | OK, I need to eat, but I think I'm starting to understand the problem you're explaining, mriedem. Namely: we can't keep a claim context going, so... I guess we'll need to shove it in the migration context, like with cold migration? | |
| 18:32:00 | mriedem | there is no reschedule or anything within the cell conductor for live migration | |
| 18:32:13 | mriedem | i guess? | |
| 18:32:25 | mriedem | the instance.migration_context is still a bit of a mystery to me | |
| 18:32:29 | mriedem | but i also need to eat | |
| 18:32:34 | artom | You and everyone else | |
| 18:32:40 | mriedem | dansmith: comments on the numa live migration spec which maybe you can answer, | |
| 18:32:43 | mriedem | re: move claims | |
| 18:32:57 | artom | I think if Nikola came back today, he'd still know more than all of us combined | |
| 18:33:15 | mriedem | on that very hairy part of the code? i agree. | |
| 18:33:28 | mriedem | there are also TODOs in there from him about the move claim stuff for reize | |
| 18:33:29 | mriedem | *resize | |
| 18:34:04 | mriedem | https://github.com/openstack/nova/blob/594c653dc1a312d0364ad24c703e1a9b228133e1/nova/compute/manager.py#L3988 | |
| 18:34:41 | mriedem | anyway, turkey leftovers | |
| 18:36:05 | sean-k-mooney | mriedem: when you are back maybe you could weigh in on https://review.openstack.org/#/c/605116/6/specs/stein/approved/libvirt-neutron-sriov-livemigration.rst@111 also. | |
| 20:59:01 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove ironic/pike note from *_allocation_ratio help https://review.openstack.org/620154 | |
| 21:15:34 | mnaser | so while answering an ML post about all_tenants and friends, i found this TODO since 2015 -- https://github.com/openstack/nova/commit/be41910ac6be28060d9007778fb33766077de59b | |
| 21:15:51 | mnaser | do we just drop that part of the code at that point? given it's been uncommented for years now | |
| 21:19:40 | artom | mriedem, does the superconductor really rescheduler if the live migrations fails? I'm looking but I can't find anything in _execute, and in the conductor manager if there's a failure in _live_migrate it just sets an error. | |
| 21:20:00 | artom | Not sure it's super relevant to the spec, but for my own personal edification | |
| 21:21:39 | mriedem | mnaser: you mean drop it at this point? | |
| 21:22:19 | mnaser | mriedem: i think so? i mean it's just dead code for 5 years, do we want to muck around with microversion bumps and blah | |
| 21:23:25 | mriedem | mnaser: tbc, you're saying just ditch the commented out code since no one cares enough to change it with a new microversion | |