| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-09-15 | |||
| 09:18:23 | lyarwood | but we aren't at rc yet soooooo | |
| 09:18:42 | lyarwood | I'd think deprecations are fine until we land the prelude and branch? | |
| 09:18:49 | bauzas | and us pushing things down the line after FF makes me a bit sad since we all communicate on the glorious ideal of whight knights only caring about bugs for the next 2 weeks | |
| 09:19:04 | bauzas | call me an idealist | |
| 09:19:32 | lyarwood | isn't that post rc? | |
| 09:19:37 | stephenfin | bauzas: personally, I can't imagine us adding anything big enough to warrant inclusion in the prelude so I think that could be fixed up to mention XenAPI/VMWareAPI changes and merged | |
| 09:19:40 | lyarwood | I know we do it between ff and rc as well | |
| 09:19:53 | lyarwood | but rc to ga is critical bugfixes etc as well right? | |
| 09:20:34 | bauzas | lyarwood: no, RCs are intended for bugfixes, including the period between M3 and RC1 | |
| 09:20:43 | stephenfin | lyarwood: on an RC-related note, what have we decided on Focal changes for Victoria? Are we simply skipping those tests until the QEMU fix lands in 20.04? | |
| 09:20:51 | bauzas | the period between RC1 and GA being focused on *regressions* | |
| 09:21:06 | stephenfin | yes, I realize I should know this already /o\ | |
| 09:21:17 | lyarwood | stephenfin: I think the TC are pushing ahead with the focal change so yeah | |
| 09:21:23 | bauzas | so in the world of OpenStack, in theory you only focus on bugs for only two weeks in a 6-month timeframe \o/ | |
| 09:21:27 | lyarwood | stephenfin: loads of jobs don't skip them still | |
| 09:25:53 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Victoria 22.0.0 prelude section https://review.opendev.org/751045 | |
| 09:26:23 | gibi | bauzas, stephenfin, lyarwood: regarding deprecatios post FF, I'm OK to finish up the xenapi removal before RC1 but in general please focus on bug triage instead of proposing new deprecations | |
| 09:26:45 | bauzas | gibi: I'm litterally on it :p | |
| 09:27:22 | bauzas | gibi: no lock held on triage ? | |
| 09:28:41 | lyarwood | stephenfin / sean-k-mooney ; https://zuul.opendev.org/t/openstack/build/11627c525c7a48138fba5d3e4c50c4e9/log/controller/logs/screen-q-dhcp.txt?severity=4 - appreciate this isn't our area but would either of you be able to look at this, I'm trying to finally sort out f32 jobs by the q-dhcp agent isn't happy, any ideas? | |
| 09:28:49 | lyarwood | https://review.opendev.org/#/c/750292/ is the review | |
| 09:29:12 | lyarwood | no idea what's borked here tbh | |
| 09:31:03 | gibi | bauzas: I don't hold the bug lock | |
| 09:31:05 | gibi | go ahead | |
| 09:33:27 | yingjisun | stephenfin: for the feature of Vendordata, is it keep running over and over when the instance is powered on ? | |
| 09:36:06 | bauzas | yingjisun: no, it's not working this way | |
| 09:36:24 | bauzas | yingjisun: it's a metadata API that instances can reach internally | |
| 09:36:36 | bauzas | exactly like the user metadata | |
| 09:37:20 | bauzas | yingjisun: so hitting this API is solely the responsability of apps running on top of the instances | |
| 09:37:25 | yingjisun | so you guess there might be some process inside the instance which keeps to invoke it ? | |
| 09:37:46 | bauzas | yingjisun: that'd be my expectations | |
| 09:37:55 | bauzas | but you can see what hits the API | |
| 09:38:03 | bauzas | so you can track | |
| 09:38:13 | brinzhang0 | stephenfin, gibi: please review this patch, followed-up with cyborg evacuate patch https://review.opendev.org/#/c/749052/ | |
| 09:39:46 | bauzas | yingjisun: see this blogpost explaining how metadata API is reached https://www.suse.com/c/vms-get-access-metadata-neutron/ | |
| 09:40:11 | yingjisun | bauzas: thank you. I read it now. | |
| 09:42:00 | bauzas | yingjisun: actually, https://docs.openstack.org/nova/latest/admin/metadata-service.html explains it better | |
| 09:43:28 | bauzas | so you can easily get the instance IP address | |
| 10:06:55 | sean-k-mooney | lyarwood i would not be surrpised if the output of the tool neutron is calling has changed | |
| 10:07:14 | lyarwood | sean-k-mooney: I can't seem to reproduce it locally | |
| 10:07:26 | lyarwood | sean-k-mooney: so it might be yet another load thing | |
| 10:10:13 | openstack | Launchpad bug 1894804 in QEMU "Second DEVICE_DELETED event missing during virtio-blk disk device detach" [Undecided,New] | |
| 10:10:13 | lyarwood | kashyap: https://bugs.launchpad.net/qemu/+bug/1894804 any news on this btw? | |
| 10:12:04 | sean-k-mooney | lyarwood: so its failing here https://github.com/openstack/neutron/blob/master/neutron/agent/linux/ip_lib.py#L955-L967 | |
| 10:13:05 | openstack | Launchpad bug 1892837 in tripleo "tempest.api.compute.servers.test_servers_negative fails in periodic-tripleo-ci-centos-8-standalone-full-tempest-api-master" [Critical,Triaged] | |
| 10:13:05 | bauzas | lyarwood: this one seems legit for Nova https://bugs.launchpad.net/nova/+bug/1892837 | |
| 10:13:52 | lyarwood | bauzas: yup less of a priority with the workaround in Tempest but still a valid Nova bug | |
| 10:14:02 | bauzas | ack, triaged. | |
| 10:14:48 | lyarwood | just cleaning up my untriaged but fix released bugs btw, appears launchpad/gerrit hasn't been keeping up | |
| 10:15:35 | sean-k-mooney | lyarwood: this might be realted to a change that merged recently. i think the if need to be split. it currently prints that message if the device does not exist or if it does not have a mac | |
| 10:16:28 | sean-k-mooney | lyarwood: is it causing the job to fail | |
| 10:17:18 | sean-k-mooney | that would be a yes it is | |
| 10:17:20 | kashyap | lyarwood: No news yet :-( - but I haven't forgotten; Was responding to something more pressing elsewhere | |
| 10:17:42 | lyarwood | sean-k-mooney: yeah AFAICT the instances aren't getting ipv4 dhcp leases and so ssh verification is failing | |
| 10:17:50 | lyarwood | kashyap: ack np just chasing up | |
| 10:17:58 | kashyap | lyarwood: Shortly, I'm going to try this experiment: | |
| 10:18:15 | lyarwood | sean-k-mooney: just finished a tox -e full tempest run on f32 without failures FWIW | |
| 10:18:21 | sean-k-mooney | lyarwood: yep from the cirros console output it has no ipv4 ip just the link local ipv6 one | |
| 10:18:41 | kashyap | lyarwood: (1) Run this vCPU-consuming 'workload' in the guest: `sha256sum /dev/zero | sha256sum /dev/zero`; (2) Attach and detach a device (or a bunch) in a loop | |
| 10:18:50 | sean-k-mooney | lyarwood: there have been issue with load and the dhcp agent in the past so you could be right that that might be the cause | |
| 10:20:20 | openstack | Launchpad bug 1894966 in OpenStack Compute (nova) "Create servergroup failed with unexpected error" [Undecided,New] | |
| 10:20:20 | bauzas | gibi: I'm tempted to close https://bugs.launchpad.net/nova/+bug/1894966 as invalid since it's a configuration problem, but we could be more preventive on the API side and serve a HTTP40x here | |
| 10:20:45 | bauzas | gibi: I feel the schema needs to be improved | |
| 10:20:50 | bauzas | you agree ? | |
| 10:21:27 | gibi | looking | |
| 10:22:20 | gibi | bauzas: agree, we need to add a better validation to the API for that | |
| 10:22:26 | bauzas | weirdo | |
| 10:22:36 | bauzas | the schema already has an enum | |
| 10:23:04 | bauzas | gibi: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/server_groups.py#L37 | |
| 10:23:23 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Include removal of ephemeral backing files in the image cache manager https://review.opendev.org/689422 | |
| 10:23:29 | bauzas | I'm not an API schema specialist, but would it prevent to have the 'policies' field to be an empty list ? | |
| 10:23:41 | bauzas | gmann: ^ (once you're up) | |
| 10:25:29 | bauzas | nevermind, we don't know the release for this bug, asking for it | |
| 10:27:05 | gibi | good point about the release and the api microversion used | |
| 10:29:31 | bauzas | but, the fact is, from v2.1 we ask policies to be set | |
| 10:29:43 | bauzas | and we only extend the enum with later microversions | |
| 10:30:37 | bauzas | so, I feel the schema allows an empty list although the comments say it shouldn't | |
| 10:30:52 | bauzas | I don't have an env started now, but the verification should be quick | |
| 10:31:00 | gibi | let me try | |
| 10:31:13 | bauzas | thanks | |
| 10:33:02 | openstack | bug 1879878 in OpenStack Compute (nova) ussuri "VM become Error after confirming resize with Error info CPUUnpinningInvalid on source node " [Undecided,In progress] https://launchpad.net/bugs/1879878 - Assigned to Stephen Finucane (stephenfinucane) | |
| 10:33:02 | openstackgerrit | Merged openstack/nova stable/ussuri: tests: Add reproducer for bug #1879878 https://review.opendev.org/751349 | |
| 10:38:53 | openstack | bug 1879878 in OpenStack Compute (nova) ussuri "VM become Error after confirming resize with Error info CPUUnpinningInvalid on source node " [Undecided,In progress] https://launchpad.net/bugs/1879878 - Assigned to Stephen Finucane (stephenfinucane) | |
| 10:38:53 | openstackgerrit | Merged openstack/nova stable/ussuri: Add generic reproducer for bug #1879878 https://review.opendev.org/751350 | |
| 10:39:22 | stephenfin | elod++ Thanks for the reviews :) | |
| 10:40:08 | elod | stephenfin: np :) | |
| 10:49:30 | openstack | Launchpad bug 1894966 in OpenStack Compute (nova) "Create servergroup failed with unexpected error" [Undecided,Incomplete] | |
| 10:49:30 | gibi | bauzas: with microversion 2.1 - 2.63 I can reproduce https://bugs.launchpad.net/nova/+bug/1894966 on master | |
| 10:49:47 | gibi | bauzas: 2.64 changed the API in a way that this problem cannot happen any more | |
| 10:50:02 | gibi | so this is a low prio bug to fix the validation of an old microversion | |
| 10:50:13 | gibi | at least for me | |
| 10:56:09 | kashyap | gibi: Hey, a random non-Nova thing :-) -- on online conferencing, I've heard really good things on this FOSS tool: 'BigBlueButton' - from the recently concluded Linux Plumbers (I didn't attend it) | |
| 10:56:19 | kashyap | gibi: But here's some notes from the co-organizer: https://lwn.net/Articles/817146/ | |
| 10:56:31 | kashyap | [quote] | |
| 10:56:33 | kashyap | To summarize, while both Jitsi and BigBlueButton are capable video-conferencing systems, BigBlueButton appears to be a more solid and feature-complete offering. In particular, the administration features and shared whiteboard capability stand out. The free-software community often struggles to create top-quality graphical applications; here we have (at least) two of them. It would appear that | |
| 10:56:39 | kashyap | there is no real need to be using proprietary solutions in this area. | |
| 10:56:41 | kashyap | [/quote] | |
| 10:57:44 | gibi | kashyap: hi! | |
| 10:58:23 | gibi | kashyap: never heard of BigBlueButton. We tried Jitsi in the last PTG and it was good except for PRC users | |
| 10:58:27 | kashyap | (Although, the above is suitable for smaller, developer events, rather than big, "red carpet public conferences") | |