| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-26 | |||
| 17:32:31 | mriedem | easy backports | |
| 17:33:57 | KeithMnemonic | thanks! | |
| 17:34:13 | mriedem | yw | |
| 17:34:18 | mriedem | thanks for the reminder | |
| 17:35:12 | sean-k-mooney | anyone know a better tool to search irc logs then googles site search | |
| 17:35:39 | cdent | edleafe made a thing, but I don't know if he made it live | |
| 17:36:29 | edleafe | sean-k-mooney: It's still rough, but you can try https://ircsearch.leafe.com | |
| 17:37:30 | sean-k-mooney | edleafe: does that use a local copy of the logs or does it search easedrop.openstack.org | |
| 17:38:00 | edleafe | sean-k-mooney: it uses its own elasticsearch database | |
| 17:39:25 | openstackgerrit | Adrian Chiris proposed openstack/nova master: add get_pci_request_from_vif to request.py https://review.openstack.org/609166 | |
| 17:39:26 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929 | |
| 17:39:26 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365 | |
| 17:39:27 | openstackgerrit | Adrian Chiris proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115 | |
| 17:44:49 | mriedem | use_cow_images=true and force_raw_images=true (defaults) is always confusing | |
| 17:46:03 | sean-k-mooney | edleafe: thanks i found the message from bauzas i was looking for but looks like he did not past the placmetend output publicaly https://ircsearch.leafe.com/timeline-middle/%23openstack-nova/2018-10-03T17:18:56 | |
| 17:46:24 | adrianc | sean-k-mooney: Hi, added you to the above commits. ive also commented on the related spec: https://review.openstack.org/#/c/605116/ | |
| 17:47:51 | sean-k-mooney | adrianc: hi i was looking at the previous version earlier today. im planning to spend tomorrow testing what you have pushed so far | |
| 17:47:59 | sean-k-mooney | adrianc: is it in a functional state | |
| 17:48:27 | edleafe | sean-k-mooney: glad it was useful for you. I wrote it because I was annoyed that I couldn't find info from a conversation | |
| 17:49:28 | sean-k-mooney | edleafe: ya i spent 20 mins looking of it with googles site: feature and did not find it | |
| 17:49:52 | adrianc | sean-k-mooney: ive tested with SRIOV MacVtap, however you it is required that the neutron mech driver to support multiple port bindings | |
| 17:49:54 | sean-k-mooney | edleafe: i found it using your seacher in 90 seocnds or so | |
| 17:50:26 | sean-k-mooney | adrianc: without the neutron change it should migration but the portstatus will be down correct | |
| 17:50:29 | adrianc | sean-k-mooney: i have a POC patch for neutron sriovnicswitch if you are interested | |
| 17:50:32 | edleafe | sean-k-mooney: the fulltext search in elasticsearch is awesome | |
| 17:50:55 | sean-k-mooney | adrianc: sure if you have it pushed i can pull it down and test with that also | |
| 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 | |