| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-26 | |||
| 17:04:13 | cdent | oh yeah that banner doth suck | |
| 17:04:15 | sean-k-mooney | e.g. in relation to db changes | |
| 17:04:21 | cdent | "someone" has a lot of work on their place | |
| 17:04:41 | mriedem | https://docs.openstack.org/nova/rocky/contributor/process.html?highlight=compatibility#smooth-upgrades | |
| 17:05:51 | sean-k-mooney | mriedem: ok so we do say we only support "only support upgrades between N and N+1 major versions, to reduce technical debt relating to upgrades" | |
| 17:06:04 | mriedem | yes, that's good enough for me | |
| 17:06:24 | mriedem | the question in -dev and the ML is if that also applies to inter-service compat | |
| 17:06:27 | mriedem | e.g. nova and cinder | |
| 17:06:30 | mriedem | and i don't think it should | |
| 17:06:37 | mriedem | b/c we have versioned REST APIs | |
| 17:07:06 | sean-k-mooney | mriedem: right if the rest apis are versioned coorectly it should not | |
| 17:07:35 | mriedem | which means you shouldn't have to take down your entire cloud to upgrade nova | |
| 17:07:44 | mriedem | i.e. you can leave cinder n-2 and upgrade nova and it should work | |
| 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: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365 | |
| 17:39:26 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929 | |
| 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 | artom: replies on the previous PS fwiw | |
| 18:17:16 | mriedem | i think you're understimating the claim issue | |
| 18:17:16 | mriedem | the claim happens on the dest before live migration starts | |
| 18:17:16 | mriedem | and returns to conductor | |
| 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 | |