Earlier  
Posted Nick Remark
#openstack-nova - 2021-01-04
09:20:18 stephenfin gibi: What do we want to do about this? https://review.opendev.org/c/openstack/python-novaclient/+/769066/
09:28:26 openstackgerrit Merged openstack/osc-placement master: remove unicode from code https://review.opendev.org/c/openstack/osc-placement/+/769059
09:30:02 openstackgerrit Merged openstack/osc-placement master: remove unicode from code https://review.opendev.org/c/openstack/osc-placement/+/769062
09:32:09 gibi stephenfin: looking
09:32:54 stephenfin Ta. Historically, mriedem had removed the novaclient features once the nova API was removed, however, since novaclient is used as a library by things like OSC, I'm not sure if we want to keep doing that
09:34:47 gibi stephenfin: I think it is OK to keep the nova client as is even for remove APIs as this code is not a big burden to maintain and as you said a new novaclient might be used towards an old nova API endpoint
09:36:55 gibi stephenfin: I don't even sure we want a deprecation message from the client itself as the server response is pretty obvious
09:37:27 stephenfin Okay, cool. Let's keep it so
09:39:03 brinzhang0 gibi, stephenfin: happy new year
09:39:50 brinzhang0 gibi, stephenfin: did you have seen my news above? pinged you yesterday
09:40:53 gibi brinzhang0: saw it but haven't looked the patches yet
09:41:29 stephenfin same
09:41:38 brinzhang0 gibi: ack, yeah, I just want to use v2.88 as the remove tenant_id microversion
09:42:28 gibi brinzhang0: I have to see what are the other patches fighting for the same microversion and how ready these patches are
09:42:33 stephenfin I was pretty sure we'd said we'd use 2.88 for the os-hypervisor work, since that's the smallest of the three items. I could have picked that up wrong though
09:43:14 stephenfin It's okay though. I think we're all aware there are competing microversion changes and can be sure to finish one before starting on the next
09:43:40 bauzas gibi: stephenfin: MHO about client changes is that we can remove old features if the API is no longer supporting it
09:44:13 bauzas but then we would have to say that the minor version supported by the client would change
09:44:16 gibi bauzas: sure we can, it is more the question if we want to remove.
09:44:24 brinzhang0 stephenfin: yeah, if possible, I can help you to change, because the remove tenant_id patach depends on 2.88, and there are some place use v2.88
09:44:50 stephenfin bauzas: what do we do about things like OSC though, that depend on the novaclient library implementation
09:45:44 bauzas stephenfin: the question is, should we still support v2.1 for the client ?
09:45:57 bauzas if yes, we *can't* remove
09:46:17 stephenfin brinzhang0: That's true for all changes. Whatever gets punted to 2.89 just has to be rebased and references to 2.88 updated to 2.89
09:47:03 stephenfin bauzas: OSC does, yes. It's supposed to support all OpenStack clouds, regardless of version (though I suspect we fall well short of that marker, and I also doubt many people are using new OSC with an e.g. Essex cloud)
09:48:36 brinzhang0 stephenfin: yeah, after you can review these patch, and pls consider waht I want to say, thanks
09:49:22 brinzhang0 and I am sure the remove tenant_id feature can be done in this release
09:50:05 brinzhang0 but as bauzas and you talked above, how to deal with the OSC changes?
09:51:04 brinzhang0 ah, maybe it's(OSC) ok for the latest changes :D
09:53:01 bauzas stephenfin: brinzhang0: see how version discovery works https://docs.openstack.org/api-guide/compute/microversions.html#version-discovery
09:53:34 bauzas given our API provides minimum as 2.0 (or 2.1, can't remember exactly which one given they are the same)
09:53:37 bauzas ,
09:54:00 bauzas then the client would have to support the minimum too
09:54:07 bauzas here, 2.1
09:54:48 bauzas actually, wrong link, https://docs.openstack.org/api-guide/compute/microversions.html#client-interaction is better
09:59:15 gibi so the conclusion could be that we can remove the CLI part but we cannot remove the lib part due to OSC
10:01:17 brinzhang0 I think yes
10:04:10 gibi stephenfin, bauzas: summarized my view in https://review.opendev.org/c/openstack/python-novaclient/+/769068
10:10:07 bauzas gibi: if we cut the support on the CLI, then we need to bump a major version when we release the client
10:10:23 bauzas but that's ok IMHO
10:10:33 gibi bauzas: correct, that is what the deprecation messages now describe in the patch
10:11:01 bauzas ack
10:14:37 gibi when (or even if ever) we cut a major version is open
10:14:52 bauzas right
10:32:48 lyarwood gibi / stephenfin ; https://review.opendev.org/c/openstack/nova/+/767590 - time to +W this?
10:33:32 openstackgerrit Merged openstack/nova master: tests: Merge 'test_hypervisor_status' into 'test_hypervisors' https://review.opendev.org/c/openstack/nova/+/764039
10:33:35 stephenfin I think so
10:35:11 lyarwood done
10:56:07 openstackgerrit Merged openstack/nova master: Run the db migration tests in the same test worker https://review.opendev.org/c/openstack/nova/+/767590
11:01:51 gibi lyarwood,stephenfin: thanks
11:01:59 gibi I will keep monitoring those tests
11:02:11 gibi as we did not solved the issue we just decreased the likelyhood
11:02:37 gibi stephen's db migration compression patch series will be an even better fix when it lands
11:11:48 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP zuul: Add nova-live-migration-ceph job https://review.opendev.org/c/openstack/nova/+/768466
11:12:46 lyarwood ^ getting close with this btw, there are some random volume backup test failures at the moment but the live migration and evacuation parts are working
11:13:39 sean-k-mooney oh nice
11:18:01 openstackgerrit Lee Yarwood proposed openstack/nova master: Add regression test for bug #1908075 https://review.opendev.org/c/openstack/nova/+/766976
11:18:03 openstack bug 1908075 in OpenStack Compute (nova) "Nova allows a non-multiattach volume to be attached to multiple instances *if* its volume state is reset by an admin" [Undecided,New] https://launchpad.net/bugs/1908075 - Assigned to Lee Yarwood (lyarwood)
11:18:03 openstackgerrit Lee Yarwood proposed openstack/nova master: api: Reject volume attach requests when an active bdm exists https://review.opendev.org/c/openstack/nova/+/768472
11:19:14 gibi stephenfin: I'm looking at the hypervisor series and wondering if the impl now in sync with the uptime change proposed in the yet unmerged spec additon here https://review.opendev.org/c/openstack/nova-specs/+/765797/1 ?
11:22:31 stephenfin gibi: I need to refresh my memory, but it doesn't appear to be, no
11:23:06 stephenfin I guess we need to approve https://review.opendev.org/c/openstack/nova-specs/+/765797/ and then I can rework. bauzas? lyarwood?
11:23:13 gibi stephenfin: so pontentially we need either a new microversion for the uptime thing or a new PS for the current hypervisor patch
11:23:51 stephenfin ideally the latter
11:24:11 stephenfin that change hardly seems worth a microversion by itself
11:24:22 sean-k-mooney i would be -1 on a microverion to readd uptime
11:25:21 sean-k-mooney so ya either respin the patch or just drop uptime would but a second micorversion for it seam excessive
11:26:45 gibi OK, I agree, let's merge that spec amendment and the respin the impl patch
11:27:11 gibi bauzas: could you look at the small spec addition at https://review.opendev.org/c/openstack/nova-specs/+/765797/1 ?
11:30:55 sean-k-mooney f**** the extra * is to account for my usual misspelling :)
11:32:12 sean-k-mooney my main server has decided to stop negocition gigabit full duplex connectivity and keeps downgrading to 100mbps but that breaks all network connectivity
11:32:51 sean-k-mooney its started doing this saturday after i rebooted it before i tried to install my gpu in it to do gpu passthough
11:33:14 sean-k-mooney so now i dont have access to any of my dev envionments...
11:33:57 sean-k-mooney also our gpu passtough works but nvida chave changed how they do the vm detachtion so the kvm hidden feature we supprot nolonger works for windows guests
11:35:16 sean-k-mooney this came up on irc a a few weeks ago acctully but i can now confirm that our current code is not sufficent, if nova users upgrade there gpu driver it there gueste will eventually stop working which is lovely
11:49:36 lyarwood sean-k-mooney:s~.
11:49:52 lyarwood urgh sorry
11:50:06 lyarwood stephenfin: sorry was afk, I'll take a look at that now
11:53:43 gibi another easy spec update needs anther core eyes https://review.opendev.org/c/openstack/nova-specs/+/768803
12:16:19 stephenfin gibi: done
12:16:38 gibi thanks
12:29:09 openstackgerrit Merged openstack/nova-specs master: [Trivial] Clarify the deprecated apis in *Proposed change* https://review.opendev.org/c/openstack/nova-specs/+/768803
12:41:46 bauzas gibi: stephenfin: sure, will look at https://review.opendev.org/c/openstack/nova-specs/+/765797/
12:47:57 gibi bauzas: thanks
12:48:06 bauzas done, +Wd
12:48:26 gibi stephenfin: you are good to go for a respin of your hypervisor patch
12:49:06 gibi meanwhile I looked at the vncconsole password patch (another microversion bump) but that is not ready yet, I still have serious comments there (not published yet)
12:49:22 gibi so right now the hypervisor patch feels the closest for the 2.88 microversion
12:49:30 gibi I will look at the tenant_id patch series too
12:54:11 openstackgerrit Merged openstack/nova-specs master: Update modernize-os-hypervisors-api spec, pt. 3 https://review.opendev.org/c/openstack/nova-specs/+/765797
13:45:00 stephenfin gibi: Yup, I'll do it now
13:45:06 gibi stephenfin: cool
14:12:55 zoharm hi, regarding proposed nvme healing agent feature: https://review.opendev.org/c/openstack/cinder-specs/+/766732
14:13:12 zoharm we would like to ask, what is the right way to spawn it? we had it proposed to use python-daemon python package for maintaining an independent process. Is it ok to add that dependency?
14:13:43 zoharm if using python-daemon is not ok, geguileo suggested previously to look at privsep daemon and see how it is spawned. which way in there is better? https://opendev.org/openstack/oslo.privsep/src/branch/master/oslo_privsep/daemon.py line 296 or 336 - we would like to have only one agent process per host. any pointers / details would be useful here. Thank you!
14:26:55 kashyap stephenfin: sean-k-mooney: Remind me again, Nova supports CPU pinnning to host core and to host NUMA node, both, yes?
14:27:32 stephenfin yes
14:27:32 sean-k-mooney kashyap: kindo of it depend on what you mean by host numa nodes
14:27:32 gibi zoharm: the nova services (daemons) using oslo_services to spawn the daemon process https://docs.openstack.org/oslo.service/latest/
14:27:52 stephenfin hw:cpu_policy=dedicated to pin to individual host cores

Earlier   Later