| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-04 | |||
| 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 | |
| 14:27:59 | sean-k-mooney | we support soft pinning so a vm will float over the cores of a singel numa node if that is what you mean | |
| 14:28:26 | sean-k-mooney | and we obvioulsy support direct 1:1 gust cpu to host cpu pinning too | |
| 14:28:39 | kashyap | I'm just asked if "CPU Pinning to host core" is supported or not | |
| 14:28:52 | sean-k-mooney | hw:numa_nodes=1 to pin the vm to just one host numa node | |
| 14:29:07 | sean-k-mooney | kashyap: you cant choose the core but yes | |
| 14:29:15 | kashyap | Okay; thx | |
| 14:29:35 | zoharm | gibi thank you, we want to do this from os-brick, is that ok? | |
| 14:29:43 | zoharm | also, any chance for a pointer at an example of how to use it? | |
| 14:29:51 | sean-k-mooney | zoharm: not really | |
| 14:30:12 | sean-k-mooney | so os-brick is shared between nova and cinder | |
| 14:30:20 | sean-k-mooney | both run as deams already and invoke the lib | |
| 14:30:39 | kashyap | stephenfin: sean-k-mooney: One more, the above of what I asked is supported from Queens, is it? | |
| 14:30:42 | sean-k-mooney | you proably should not be sapawning a second deamon out of the os-brick lib | |
| 14:30:51 | zoharm | right, but we need an entry point for the agent/daemon as per the spec, and the connector is the place decided on | |
| 14:31:03 | zoharm | do you have an alternative? | |
| 14:31:35 | bnemec | zoharm: If you want to know more about how privsep works, you can read about it in https://github.com/openstack/oslo.privsep/blob/master/oslo_privsep/daemon.py#L15 | |
| 14:31:40 | sean-k-mooney | zoharm: a better apprcoh would be to have a seperate console script entry point that is run seperatly as a deamon and no tspawned out of eithet the nova-compute process or the cinder-volume process | |
| 14:32:12 | zoharm | what is a console script? | |
| 14:32:41 | zoharm | we are aware of the option of having an external script, but the goal here is to get it into openstack | |
| 14:32:42 | sean-k-mooney | zoharm: its a setuptool entroy point that creates a indepenten binary that you can run in the termal | |
| 14:33:07 | zoharm | ok that sounds interesting, can you give me a reference / example? | |
| 14:33:19 | sean-k-mooney | sure on sec | |
| 14:33:45 | zoharm | and proposal is not to run it from terminal, but have openstack run it only when needed. | |