Earlier  
Posted Nick Remark
#openstack-nova - 2021-03-30
11:00:51 kashyap stephenfin: Looks fine to me; just looked
11:25:07 kashyap stephenfin: I'm somewhat ambivalent about the folding in here: https://review.opendev.org/c/openstack/nova/+/782411
11:26:06 kashyap I'm not against it; but just that sometimes having the separate doc w/ a single focus can be less distracting. One can link to the other, generic CPU modelss doc, though.
11:31:48 sean-k-mooney kashyap: too much linking can make reading them in git/github or pdf form so its a trade off but ya topic docs can be useful. i dont partically like the extream we take it to downstream
12:01:55 sean-k-mooney stephenfin: do you have a partical wording you would like me to add for the release note in the cpu_max_* patch
12:28:13 gibi stephenfin: I guess it is OK that these docs are only merged for Xena now
12:33:32 sean-k-mooney stephenfin: https://review.opendev.org/c/openstack/nova/+/769614/2//COMMIT_MSG#18 is that better?
12:34:32 kashyap sean-k-mooney: Yeah; I hear ya
12:50:39 stephenfin gibi: I think so, yeah
12:51:17 gibi stephenfin: OK, cool, I'm working through it
12:54:38 stephenfin sean-k-mooney: Yeah, that makes sense. So iiuc what we want to say is that previously we would attempt to best map the guest NUMA topology of pinned instances to the host NUMA topology, but that was buggy and wasn't updated e.g. during live migration so it's been removed?
12:55:24 sean-k-mooney well i could say that or i could try an implemente it ussing toplogy sorting
12:55:31 sean-k-mooney rahter then filtering
12:55:44 sean-k-mooney i feel like that should be a sperate patch however
12:58:25 sean-k-mooney if i proceed with removal of the code then yes ill update the release as you sugesst noting we tired but it was buggy and now removed
13:04:27 stephenfin makes sense
13:20:51 sean-k-mooney stephenfin: what would you like me to do note we remove the behavior and try and add the sorting in a follow up, add the sortign first in a prevous patch or just remove the behavior and note it
13:21:16 stephenfin I think the sorting should probably be separate so a follow-up?
13:26:36 sean-k-mooney ok ill adress the other comments so and then ill push and start working on the follow up
13:28:05 sean-k-mooney thanks for persiting with this i was exclusivly thinking baout this form the point of view of unpinned guests with numa toplogies
13:39:44 bauzas gibi: I only see one bugfix with https://bugs.launchpad.net/nova/+bugs?field.tag=wallaby-rc-potential
13:40:08 bauzas gibi: stephenfin: what about the cpu_max patch ?
13:40:36 stephenfin I don't think so. It's latent
13:41:10 bauzas https://review.opendev.org/q/project:openstack/nova+branch:stable/wallaby we only merged lyarwood's patch for os-brick
13:41:20 bauzas ok, so for the moment, only one patch for RC2
13:41:31 bauzas gibi: when are you planning the RC2 release ?
13:48:43 sean-k-mooney bauzas: ya the cpu max patch is not an rc candiate
13:48:54 bauzas ack
13:49:11 sean-k-mooney ill backport it to stable/wallaby as normal once we do the release.
13:53:18 bauzas all good
13:56:27 bauzas folks, I think we have a consensus about nova shouldn't supporting rabbit MQs be unstable, right?
13:56:32 bauzas context : https://bugs.launchpad.net/nova/+bug/1921804
13:56:35 openstack Launchpad bug 1921804 in OpenStack Compute (nova) "leftover bdm when rabbitmq unstable" [Undecided,New]
13:57:06 dansmith bauzas: I think we have always said, and can only say, that we expect rabbit to work, yes
13:57:26 bauzas yup
13:57:50 bauzas I'll move the bug status to Wontfix
13:58:07 dansmith if there's some particularly nasty bug we create for ourselves if rabbit breaks at some specific time, then mitigating that would be good, but I think in general we should expect rabbit to work
14:00:43 gibi bauzas: agreed about the leftover bdm, until it does not create a failure later just leaks some db resources then I'm OK to move it to wontfix
14:00:48 bauzas the bug is about the fact that we create a bdm even the volume is not attached
14:08:24 bauzas mmm, maybe we should document this in https://docs.openstack.org/nova/latest/contributor/project-scope.html
14:11:35 gibi bauzas: about the RC2, release should be cheap, but we don't have to rush. It is totally OK to have the RC proposed early next week.
14:11:44 bauzas yup
14:11:55 bauzas my question was more about the time we need to look at existing bugs
14:12:05 gibi looking now is good
14:12:07 bauzas as we could find regressions
14:12:27 bauzas I don't want to create a RC2 this week if we need another RC3 eventually
14:12:38 gibi yupp
14:47:15 gibi stephenfin: FYI there is a rendering issue in https://review.opendev.org/c/openstack/nova/+/781438/2/doc/source/admin/cpu-models.rst#60 but not serious so I'm OK if it is fixed in a fup
14:47:56 stephenfin damn, ack - will do a follow-up
15:01:07 sean-k-mooney stephenfin: so the max cpu error. it looks like that only happens when pinning is enabled
15:01:28 sean-k-mooney when i remove hw:cpu_policy=dedicated it goes away
15:01:31 stephenfin yeah, that would make sense based on my comments
15:01:59 sean-k-mooney ya so ill leave that in the extra specs with hw:mem_page_size=small
15:04:34 sean-k-mooney actully ill use hw:mem_page_size='any' its technically not required but its incorrect to not set it
#openstack-nova - 2021-03-31
00:17:34 openstackgerrit sean mooney proposed openstack/nova master: Test numa and vcpu topologies bug: #1910466 https://review.opendev.org/c/openstack/nova/+/769601
00:17:36 openstackgerrit sean mooney proposed openstack/nova master: Fix max cpu topologies with numa affinity https://review.opendev.org/c/openstack/nova/+/769614
00:17:36 openstack bug 1910466 in OpenStack Compute (nova) "NUMA instance spawn fails on get_best_cpu_topology when there is no 'threads' preference" [Medium,In progress] https://launchpad.net/bugs/1910466 - Assigned to sean mooney (sean-k-mooney)
01:11:13 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Re-propose Remove tenant_id https://review.opendev.org/c/openstack/nova-specs/+/783783
07:17:19 sorin-mihai is it possible to avoid getting .novalocal appended to the hostname of the instances?
07:24:20 openstackgerrit Merged openstack/nova master: docs: Clarify value for 'hw:cpu_realtime' extra spec https://review.opendev.org/c/openstack/nova/+/782708
07:32:36 openstackgerrit Balazs Gibizer proposed openstack/placement master: Add support for RP re- and un-parenting https://review.opendev.org/c/openstack/placement/+/784020
08:03:10 openstackgerrit Balazs Gibizer proposed openstack/osc-placement master: Mark microversion 1.37 support https://review.opendev.org/c/openstack/osc-placement/+/784023
08:03:37 openstackgerrit Balazs Gibizer proposed openstack/osc-placement master: Mark microversion 1.37 supported https://review.opendev.org/c/openstack/osc-placement/+/784023
08:23:53 bauzas just in case sorin_mihal goes back : https://docs.openstack.org/nova/latest/configuration/config.html#api.dhcp_domain
09:43:02 openstackgerrit Merged openstack/nova master: docs: Use proper headers in nova-manage man page https://review.opendev.org/c/openstack/nova/+/726191
09:52:25 gibi_away I will be away mostly this afternoon
10:11:50 openstackgerrit Merged openstack/nova stable/victoria: api: Log os-resetState as an instance action https://review.opendev.org/c/openstack/nova/+/772480
10:31:36 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Further tweaks to the CPU models document https://review.opendev.org/c/openstack/nova/+/784066
10:32:02 stephenfin sean-k-mooney: ^
10:33:39 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Further tweaks to the CPU models document https://review.opendev.org/c/openstack/nova/+/784066
10:38:09 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Correct typos in 'nova-manage db' docs https://review.opendev.org/c/openstack/nova/+/784067
10:39:31 openstackgerrit Merged openstack/nova stable/ussuri: Make _rebase_with_qemu_img() generic https://review.opendev.org/c/openstack/nova/+/780780
10:40:09 openstackgerrit Merged openstack/nova stable/ussuri: Use absolute path during qemu img rebase https://review.opendev.org/c/openstack/nova/+/757083
10:40:28 openstackgerrit Merged openstack/nova stable/ussuri: libvirt: Use specific user when probing encrypted rbd disks during extend https://review.opendev.org/c/openstack/nova/+/773444
10:55:34 openstackgerrit Claudiu Belu proposed openstack/nova stable/train: WIP: live migration: Pass limits onto scheduler-chosen destination https://review.opendev.org/c/openstack/nova/+/784071
11:02:13 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Correct typos in 'nova-manage cells_v2' docs https://review.opendev.org/c/openstack/nova/+/784073
12:45:12 openstackgerrit Merged openstack/nova stable/train: Test for disabling greendns https://review.opendev.org/c/openstack/nova/+/761763
13:09:30 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: trivial: Fix spelling, formatting of vDPA spec https://review.opendev.org/c/openstack/nova-specs/+/781260
14:43:59 kashyap stephenfin: Are you sure the default for AArch64 is coming from libvirt, instead of QEMU?
14:44:05 kashyap (For 'host-passthrough', i.e)
14:44:16 stephenfin nope
14:44:52 kashyap I'll confirm on the change; let me look in the code
14:45:03 kashyap And also ask an AArch64 dev, for good measure
14:46:27 kashyap I discussed this on an upstream docs change ... /me goes to find the link
14:47:19 kashyap stephenfin: Okay, from my own review comment:
14:47:25 kashyap For AArch64, we now set the ``max`` as the default CPU model; it does the right thing in context of both QEMU TCG (plain emulation) and for KVM (hardware acceleration).
14:47:25 kashyap [quote]
14:47:29 kashyap [/quote]
14:47:59 kashyap stephenfin: So I don't know where you got that 'host-passthrough' bit for AArch64; I'll comment on the change for the record
14:48:21 stephenfin I think that was based on comments from sean-k-mooney
14:48:47 kashyap That's incorrect, I'm afraid
14:51:45 kashyap stephenfin: Unlike x86, AArch64 does not even _have_ a default CPU model. We discussed it at length in this patch here: https://review.opendev.org/c/openstack/nova/+/709494
14:56:11 sean-k-mooney kashyap: not accoundign to the code
14:56:33 kashyap sean-k-mooney: Very well it is; according to the code
14:56:44 kashyap https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4753
14:56:53 kashyap sean-k-mooney: And see this release note: https://review.opendev.org/c/openstack/nova/+/709494/21/releasenotes/notes/bug-1864588-737c29560effd16e.yaml
14:57:20 kashyap Which I recall distinctly asking to word it that way (because it's truth) :)
15:05:44 sean-k-mooney ill be starting the call soon by the way
15:05:50 sean-k-mooney just fisnihgn a differnt call
15:06:06 sean-k-mooney oh upstream yeah :)

Earlier   Later