Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-30
16:05:09 lyarwood melwitt: ack looking
16:06:29 elod melwitt: will do that in ~1-2 hrs
16:07:01 melwitt thanks
16:10:27 openstackgerrit Thomas Goirand proposed openstack/nova master: Add a /healthcheck URL https://review.opendev.org/724684
16:15:49 sean-k-mooney kashyap: ok i guess i just has an invalid config i was try to convert an existing instance but now that i think about it i proably also did not have a biosboot partion or a gpt partion table for that matter in the vm since it was originally booted wit a legacy bios
16:16:01 sean-k-mooney so ya that is proably the same issue i hit
16:16:08 kashyap Yes, having an EFI partition is critical :)
16:25:48 stephenfin lyarwood, melwitt: Two noddy patches for a stable core here https://review.opendev.org/#/c/722961/ https://review.opendev.org/#/c/722962/
16:26:39 lyarwood stephenfin: ack looking
16:27:20 lyarwood oh openstack/placement
16:27:26 lyarwood stephenfin: I'm not a stable core theree
16:27:29 lyarwood there*
16:27:45 stephenfin then who is?
16:27:52 stephenfin I honestly expected to be in that group :/
16:27:57 melwitt ah, me neither. and no I did not know the word "noddy" :)
16:28:57 lyarwood I now have the song stuck in my head, thanks stephenfin
16:29:30 lyarwood stephenfin: https://review.opendev.org/#/admin/groups/1938,members - we might want to fix this
16:29:49 lyarwood stephenfin: something for the ptg, the project just came up in the meeting anyway FWIW
16:30:27 lyarwood stephenfin: https://review.opendev.org/#/admin/groups/1936,members - tbh you and others who are already cores should be copied across
16:32:18 stephenfin efried: any chance of adding nova-stable-maint to placement-stable-maint, assuming you think that makes sense?
16:32:26 lyarwood or that
16:32:52 stephenfin why wait ¯\_(ツ)_/¯
16:33:17 stephenfin efried: https://review.opendev.org/#/admin/groups/540,members and https://review.opendev.org/#/admin/groups/1938,members fwiw
16:36:59 efried stephenfin: I don't think I haven any control over stable anything.
16:37:23 stephenfin you're in placement-stable-maint so this might be the sole exception :)
16:37:34 efried o rite
16:40:12 efried stephenfin: I don't think it makes sense to include by group. I could cherry pick names that make sense, like dansmith and melwitt. But if someone is in nova-stable-maint but not in stable-maint-core it's because they know nova, which doesn't necessarily mean they know placement.
16:41:32 efried Added dansmith and melwitt.
16:41:39 stephenfin I've found these things to be self-selecting, personally. I'm stable core in all oslo stuff but there are backports I won't touch with a stick because I don't grok them (anything oslo.concurrency, for one)
16:41:43 stephenfin but that's fair
16:44:00 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add nova-status upgrade check and reno for policy new defaults https://review.opendev.org/723645
16:44:31 efried Having had two no-longer-working-in-openstack names on the list before was understandably brittle, esp considering stable-maint-core really only has one member who's active. But Dan and Mel should be able to bootstrap it from here as appropriate.
16:46:47 gibi efried: thanks for fixing that up
16:48:21 dansmith bauzas: are these proposed yet? I don't see them if you're the owner
16:48:30 bauzas dansmith: artom
16:49:35 bauzas dansmith: https://review.opendev.org/#/q/topic:placement-audit-backport+(status:open+OR+status:merged)
16:49:54 bauzas he proposed the patches, I just expressed the opportunity to un-DNM them
16:50:17 dansmith that's quite a stack of dependencies too
16:50:38 artom dansmith, the stein one is the last self-contained one, and even then it's kinda fugly
16:50:45 artom rocky's a horror (picture show)
16:50:47 artom :D
16:53:22 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add nova-status upgrade check and reno for policy new defaults https://review.opendev.org/723645
17:04:22 dansmith artom: so looking at it, the train one isn't terrible, and if it's really likely that people will need this then I guess it's okay, although I feel like having outstanding issues would be a stronger case
17:04:41 dansmith especially since they can fix one-off issues with osc-placement quite easy, and there are community tools to do it
17:04:45 openstackgerrit OpenStack Release Bot proposed openstack/os-vif stable/ussuri: Update .gitreview for stable/ussuri https://review.opendev.org/724712
17:04:46 openstackgerrit OpenStack Release Bot proposed openstack/os-vif stable/ussuri: Update TOX_CONSTRAINTS_FILE for stable/ussuri https://review.opendev.org/724713
17:04:48 openstackgerrit OpenStack Release Bot proposed openstack/os-vif master: Update master for stable/ussuri https://review.opendev.org/724714
17:04:49 artom dansmith, so, full disclosure, I don't really care one or another :P
17:04:49 openstackgerrit OpenStack Release Bot proposed openstack/os-vif master: Add Python3 victoria unit tests https://review.opendev.org/724715
17:04:53 dansmith the stein one, while self-contained is already pretty smelly
17:05:06 artom dansmith, as I said, it was purely procedural for me - I wanted to do it one release at a time, and upstream CI on it
17:05:07 dansmith and beyond stein I think it's unreasonable without a major issue, personally
17:05:17 dansmith artom: ack
17:05:34 bauzas lemme look why we needed this command
17:05:40 bauzas ie. which bugs leaked the allocations
17:05:58 bauzas some of them were old and are fixed, some of them still exist IIRC
17:06:05 artom dansmith, so I'd be perfectly comfortable doing it downstream-only
17:06:17 artom dansmith, assuming you don't destroy the case for that as well ;)
17:06:33 artom I probably didn't do enough "due diligence", and just blindly went ahead and started cherry-picking
17:06:48 dansmith artom: you know I just love crushing hopes and dreams right?
17:06:53 dansmith (I really don't despite what you probably think)
17:07:03 artom dansmith, I know. How do you think I became such an empty husk? :)
17:07:53 bauzas https://review.opendev.org/#/c/670112/14/nova/tests/functional/test_nova_manage.py are the cases we verify
17:16:14 bauzas so I've tested three cases
17:16:25 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Note the ``hw_numa_nodes`` image property https://review.opendev.org/683849
17:16:32 bauzas 1/ deleted instances leak allocations
17:16:50 bauzas 2/ resize confirm can also leak allocations
17:17:02 bauzas 3/ deleted compute evacuate too
17:17:22 bauzas now, the question is, which bugs are those 3 checks related with ?
17:17:46 bauzas the last one is easy
17:18:01 openstack Launchpad bug 1829479 in OpenStack Compute (nova) "The allocation table has residual records when instance is evacuated and the source physical node is removed" [Medium,In progress] - Assigned to Matt Riedemann (mriedem)
17:18:01 bauzas https://bugs.launchpad.net/nova/+bug/1829479
17:22:04 openstack Launchpad bug 1829479 in OpenStack Compute (nova) "The allocation table has residual records when instance is evacuated and the source physical node is removed" [Medium,In progress] - Assigned to Matt Riedemann (mriedem)
17:22:04 bauzas dansmith: artom: just to finish, I think https://bugs.launchpad.net/nova/+bug/1829479 impacts all releases up to now
17:22:19 bauzas which makes the audit command a good workaround for it
17:22:46 bauzas anyway, /me disappears
17:22:50 dansmith okay I'm confused.. are we still arguing to backport this or what?
17:23:53 dansmith did we fix the leak due to evacuation or are we saying the fix for that is just to have the audit command?
17:24:05 dansmith obviously for things that happened before such a fix, audit could help
17:26:35 bauzas dansmith: nope, we haven't fixed it yet
17:26:50 dansmith okay I would be in favor of backporting *that* :)
17:26:53 bauzas the audit command just cleans the mess
17:28:00 bauzas anyway, I need a beer
17:49:36 mriedem https://review.opendev.org/#/c/678100/
17:57:25 openstackgerrit sean mooney proposed openstack/nova master: [DNM] testing with force_legacy_port_binding workaround https://review.opendev.org/724387
18:03:19 melwitt mriedem: want an e-r stat? https://review.opendev.org/724719
18:04:18 mriedem bauzas: no just linking in bugs that are assigned to me
18:08:41 mriedem melwitt: commented
18:08:59 mriedem it's weird but the before and after on that query are on the same change, and in the new query they are all coming from the same file (n-cpu in the subnode)
18:09:02 mriedem is that expected?
18:09:15 mriedem was qemu or libvirt bumped in devstack on master?
18:11:17 melwitt mriedem: ah dangit ... I focused on the error log message and didn't notice the warning log is what's in the e-r query. so the query doesn't need an update. sorry :(
18:13:49 openstackgerrit sean mooney proposed openstack/nova master: silence amqp heartbeat warning https://review.opendev.org/724188
18:13:50 openstackgerrit sean mooney proposed openstack/nova master: remove support of oslo.messagiang 9.8.0 warning message https://review.opendev.org/724725
18:13:59 melwitt and since the bug was greyed out on http://status.openstack.org/elastic-recheck/#1840159 at the time, that reinforced my thinking that the query didn't pick it up. sigh
18:21:40 mriedem \o/
18:33:54 gmann dansmith: gibi this is ready - https://review.opendev.org/#/c/723645/
18:49:04 dansmith gmann: a couple more wording clarification tings
18:49:06 dansmith *things
19:18:18 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add nova-status upgrade check and reno for policy new defaults https://review.opendev.org/723645

Earlier   Later