Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-26
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: 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 ?

Earlier   Later