| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-30 | |||
| 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 | |
| 19:18:21 | gmann | dansmith: updated ^^ | |
| 19:19:43 | dansmith | gmann: okay lemme just fix another thing in-line to avoid you having to do it | |
| 19:20:00 | gmann | dansmith: sure, thanks | |
| 19:20:56 | dansmith | gmann: is it "recommended" or "required" to enable enforce_scope if you have scope checking rules? | |
| 19:21:02 | dansmith | I thought required | |
| 19:21:22 | gmann | dansmith: this is separate flaf not scope one - enforce_new_defaults | |
| 19:21:24 | gmann | flag | |
| 19:21:42 | gmann | to switch to new default without overwriting the file | |
| 19:22:01 | dansmith | gmann: right, but if you have scope-checking rules and want to keep them, then you need enforce_scope=True right? | |
| 19:22:14 | dansmith | you're checking enforce_scope, but if that's disabled, you tell them to enable enforce_new_defaults | |
| 19:23:07 | gmann | dansmith: ok, so enforce_scope=True is required and (enforce_new_defaults=True OR file overwrite) to move to new things | |
| 19:23:24 | dansmith | right, I think you're telling them the wrong thing | |
| 19:23:33 | dansmith | let me comment for context and you can see if I'm right | |
| 19:23:39 | gmann | in that sentence i was targeting only file overwrite alternate via flag | |
| 19:24:00 | gmann | but i agree we can add enforce_scope=True also for full context | |
| 19:25:19 | dansmith | but the sentence is about keeping the new format | |
| 19:25:24 | dansmith | U cinnebted | |
| 19:25:26 | dansmith | whoa | |
| 19:25:28 | dansmith | "I commented" | |
| 19:33:26 | gmann | dansmith: replied, https://review.opendev.org/#/c/723645/11/nova/cmd/status.py@358 | |
| 19:33:38 | gmann | added scope and new flag way. | |
| 19:34:24 | dansmith | gmann: ++ | |
| 19:34:28 | gmann | my intention is they are aware of new flag enforce_new_defaults t o avoid legacy way of overwriting the file to new default | |