| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-26 | |||
| 17:07:51 | mriedem | we don't test it, but it should work | |
| 17:08:04 | mriedem | unless otherwise noted as we've dropped some compat | |
| 17:08:15 | sean-k-mooney | yes you should be able to do a service wise rolling upgrade | |
| 17:08:31 | sean-k-mooney | and you should be able to skip upgrade some services if you dont need too | |
| 17:09:51 | sean-k-mooney | i generally parsed the version n contolplane with n-1 agents compatiablity to only applcy within a singel service | |
| 17:11:48 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: [stable-only] Add report_ironic_standard_resource_class_inventory option https://review.openstack.org/620111 | |
| 17:13:06 | mriedem | smcginnis: cdent: regarding that question about nova requiring cinder >= rocky, i'll likely drop the API compat we have for cinder < rocky (really queens b/c nova-api checks for cinder 3.44 which was added in queens), with a release note and potentially an upgrade check to look at the service catalog and make sure cinder >= 3.44 is available | |
| 17:14:53 | smcginnis | mriedem: Queens should be a good point. I would think from there we can probably clean up a lot of code. | |
| 17:15:51 | mriedem | still need my patches to migrate old bdm attachments, as discussed in berlin, | |
| 17:16:03 | mriedem | or do someone online when the attachments are used, but i haven't put brain power into that | |
| 17:16:35 | mriedem | definitely need https://review.openstack.org/#/c/541420/ for bfv though | |
| 17:31:04 | KeithMnemonic | mriedem is there a chance to get some cores to review your patch https://review.openstack.org/#/c/614872/1 ? | |
| 17:31:08 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: [stable-only] Add report_ironic_standard_resource_class_inventory option https://review.openstack.org/620113 | |
| 17:32:19 | mriedem | KeithMnemonic: queens needs to go first https://review.openstack.org/#/c/614868/ | |
| 17:32:27 | mriedem | but yeah dansmith lyarwood https://review.openstack.org/#/q/I98a2785c07f7af02ad83650c72d9e1868290ece4 | |
| 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 | |