Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-26
16:32:01 dansmith sorry verify_noapi preupgrade
16:33:41 dansmith https://review.openstack.org/620104
16:34:00 dansmith mriedem: anyway, don't lose sleep over it, I'll check in on that later to see how it goes
16:34:11 mriedem ack thanks
16:45:14 openstackgerrit Adam Spiers proposed openstack/nova-specs master: Add spec for libvirt driver launching AMD SEV-encrypted instances https://review.openstack.org/609779
16:59:53 mriedem i guess we never documented anywhere officially that we only support n-1 computes..
16:59:57 mriedem even though it comes up every so often
17:00:55 sean-k-mooney compute older then n-1 may work in some cases however we just dont test them
17:01:45 mriedem yes i know that.
17:01:59 mriedem what i'm asking is, didn't we ever document this because the last time it came up, i thought we said someone would document it.
17:02:04 mriedem which is i guess why it didn't get done.
17:03:39 mriedem https://docs.openstack.org/nova/rocky/contributor/project-scope.html?highlight=compatibility#upgrade-expectations is about as close as it gets
17:03:48 mriedem fuck i hate that banner
17:04:00 sean-k-mooney we dont state i t explictily in https://docs.openstack.org/nova/rocky/user/upgrade.html#rolling-upgrade-process but we do mention n to n+1 a few times
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

Earlier   Later