| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-08-02 | |||
| 08:15:42 | bauzas | gibi: good morning and welcome back | |
| 08:17:05 | bauzas | hope you had a good rejuvenated week | |
| 08:18:39 | gibi | bauzas: thanks it was good, thanks | |
| 08:19:02 | gibi | bauzas: anything major I should now about from last week? | |
| 08:20:07 | bauzas | gibi: honestly, no | |
| 08:20:22 | bauzas | I just saw melwitt's thread about the CI issue in this weekend | |
| 08:20:43 | bauzas | but we didn't have any problems before | |
| 08:23:05 | gibi | bauzas: yepp that is time sensitive, it hits on every last day of a month | |
| 08:23:19 | gibi | so it only failed on 31th | |
| 08:23:45 | gibi | melwitt: has a fix proposed but I'd like to test is in a VM where the clock is set back to 31th | |
| 08:23:55 | gibi | s/test is/ test it/ | |
| 10:52:29 | lyarwood | gibi / sean-k-mooney / stephenfin ; https://github.com/openstack/nova/blob/5a56ac42ad24d74a2bc150769fd2d2fdcbfa3fd6/nova/compute/manager.py#L8873-L8875 - stupid question, is this actually a no-op for Neutron? If so any objections if I remove it? | |
| 10:53:12 | lyarwood | unless it's already called | |
| 10:53:44 | lyarwood | oh right it's already called during pre_live_migration | |
| 10:58:27 | opendevreview | Lee Yarwood proposed openstack/nova master: WIP compute: Remove no-op setup_networks_on_host calls https://review.opendev.org/c/openstack/nova/+/803191 | |
| 11:20:32 | gibi | lyarwood: yepp | |
| 11:25:23 | lyarwood | kk I'll see what ^ borks in terms of tests and go from there | |
| 11:25:42 | dbulira | filters or Placement. Is there a way of setting up separate quotas for various vCPUs (cores) for a single project? Similarly what is done in Cinder when you have general quota for gigabytes and per-storage-type specific one. Any hint where to look at is highly welcomed. | |
| 11:25:42 | dbulira | Hi! Sorry for dropping the question here, however didn't get attention in the general channel. I have a general question regarding quotas in Nova. Let's assume I have two tiers of vCPUs lowfreq and highfreq or any other division (AMD/Intel, etc.). They are of course kept in separate host-aggregates and instance-host filtering is done via scheduler | |
| 13:39:10 | opendevreview | Jacek Tomasiak proposed openstack/nova stable/rocky: Reject open redirection in the console proxy https://review.opendev.org/c/openstack/nova/+/803182 | |
| 14:43:13 | opendevreview | Merged openstack/nova master: Restore original time override in test_archive_task_logs https://review.opendev.org/c/openstack/nova/+/803106 | |
| 15:24:59 | gibi | stephenfin: do you mean missing unit test coverage here? https://review.opendev.org/c/openstack/nova/+/793620/13#message-51af15791583c674361ebd329cab0759e2297d4d | |
| 15:25:31 | gibi | stephenfin: as there is a set of functional tests covering the modified APIs there | |
| 16:00:24 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Clean up unreal UUID values in tests https://review.opendev.org/c/openstack/nova/+/803226 | |
| 16:42:50 | opendevreview | Sylvain Bauza proposed openstack/nova master: Provide the mdev class for every PCI device https://review.opendev.org/c/openstack/nova/+/802918 | |
| 16:42:51 | opendevreview | Sylvain Bauza proposed openstack/nova master: Provide and use other RCs for mdevs if needed https://review.opendev.org/c/openstack/nova/+/803233 | |
| 16:42:51 | opendevreview | Sylvain Bauza proposed openstack/nova master: DNM (yet) : Expose the mdev class https://review.opendev.org/c/openstack/nova/+/801743 | |
| 17:15:10 | opendevreview | Sylvain Bauza proposed openstack/nova master: WIP : Expose the mdev class https://review.opendev.org/c/openstack/nova/+/801743 | |
| 17:15:10 | opendevreview | Sylvain Bauza proposed openstack/nova master: Provide and use other RCs for mdevs if needed https://review.opendev.org/c/openstack/nova/+/803233 | |
| 22:19:12 | opendevreview | Samuel proposed openstack/nova-specs master: Migrate Instance Between Projects https://review.opendev.org/c/openstack/nova-specs/+/802034 | |
| #openstack-nova - 2021-08-03 | |||
| 01:03:41 | songwenping | bauzas, sean-k-mooney[m]: thanks for last week's response. | |
| 07:29:25 | bauzas | gibi: morning | |
| 07:29:35 | bauzas | looks like the nova-lvm job is on the weeds | |
| 07:32:15 | gibi | bauzas: o/ I have to be off for 2 hours | |
| 07:33:12 | bauzas | no worries, I'll try to look at the problme | |
| 07:33:12 | gibi | it seems it is in the weeds for daays | |
| 07:33:15 | bauzas | yup | |
| 07:33:28 | bauzas | a snapshot not found or something like this | |
| 07:33:52 | gibi | last success was 2021-07-16T08:36:39 | |
| 07:34:08 | bauzas | yep http://logstash.openstack.org/#dashboard/file/logstash.json?query=build_name%3A%5C%22nova-lvm%5C%22%20build_status%3A%5C%22FAILURE%5C%22 | |
| 07:34:16 | bauzas | (if logstash is still working correctly) | |
| 07:35:25 | gibi | but then how we managed to merge things?! | |
| 07:35:43 | gibi | was this job turned off? | |
| 07:36:43 | gibi | or is it selectively runnig? | |
| 07:37:36 | gibi | it doesn't have a too special irrelevant-files in .zuul.yaml | |
| 07:37:40 | gibi | so I don't get it | |
| 07:37:48 | gibi | I have a bunch of patches that nova-lvm isn't run on | |
| 07:38:00 | bauzas | excellent question | |
| 07:38:11 | gibi | like https://review.opendev.org/c/openstack/nova/+/800086/13 | |
| 07:38:23 | gibi | pingig lyarwood :) | |
| 07:38:27 | bauzas | zuul is pretty https://zuul.openstack.org/builds?job_name=nova-lvm | |
| 07:38:44 | bauzas | none of the job builds worked since 2 weeks | |
| 07:38:44 | gibi | and I'm dropping off now. be back later | |
| 07:38:51 | bauzas | gibi: no worries and thanks | |
| 07:40:05 | yonglihe | HI, everyone | |
| 07:42:55 | bauzas | ok, the nova-lvm job is triggered on libvirt changes hence the non-failure on other changes and why we merged other stuff | |
| 07:43:01 | bauzas | https://zuul.openstack.org/job/nova-lvm | |
| 07:43:39 | bauzas | now, looks like all runs fail with the same tempest tests with the same exception being a snapshot not found | |
| 07:46:33 | bauzas | huzzaaaaah \o/ https://zuul.openstack.org/build/a04b0d2e184a4d3e9c39bd6110b454ea/log/controller/logs/screen-n-cpu.txt?severity=4#12685-12689 | |
| 07:46:44 | bauzas | NotImplementedError: direct_snapshot() is not implemented | |
| 07:47:12 | bauzas | looks like we regressed | |
| 07:51:29 | bauzas | hmmmm | |
| 07:51:53 | lyarwood | Morning | |
| 07:52:09 | lyarwood | yeah I've not had time to look at nova-lvm failures thanks to a few downstream fires | |
| 07:52:17 | lyarwood | they should be out now so I'll look this morning | |
| 07:52:20 | bauzas | ok, I have better understanding | |
| 07:52:22 | lyarwood | bauzas: that isn't the failure | |
| 07:52:25 | bauzas | correct | |
| 07:52:33 | bauzas | we catch the notimplemented exception | |
| 07:52:36 | bauzas | it's failing later | |
| 07:52:51 | bauzas | when calling glance I'd say | |
| 07:53:06 | bauzas | https://zuul.openstack.org/build/a04b0d2e184a4d3e9c39bd6110b454ea/log/controller/logs/screen-n-cpu.txt?severity=4#12772 | |
| 07:53:08 | lyarwood | yeah the g-api 502 is something I think I've seen before when we run out of space during the upload | |
| 07:53:27 | bauzas | yup | |
| 07:53:57 | bauzas | we want to upload the snapshot and we fail, right? | |
| 07:54:22 | lyarwood | we are in the process of uploading the snapshot and something fails | |
| 07:54:29 | lyarwood | it might even be a timeout in httpd | |
| 07:54:39 | lyarwood | given the size of the images we are uploading for these tests | |
| 07:55:18 | lyarwood | brb | |
| 07:56:23 | bauzas | lyarwood: https://zuul.openstack.org/build/a04b0d2e184a4d3e9c39bd6110b454ea/log/controller/logs/screen-g-api.txt?severity=3#3555 | |
| 07:56:37 | bauzas | this error matches the req-id of the n-cpu issue | |
| 08:11:54 | bauzas | well, can't figure out more why the temporary image fails | |
| 08:12:09 | bauzas | abhishekk: around ? | |
| 08:12:43 | bauzas | abhishekk: we have a nova job failure (nova-lvm) which fails constantly because of glance API returning 502 https://zuul.openstack.org/build/a04b0d2e184a4d3e9c39bd6110b454ea/log/controller/logs/screen-g-api.txt?severity=3#3555 | |
| 08:12:55 | bauzas | on an image upload | |
| 08:34:47 | abhishekk | bauzas, looking | |
| 08:35:02 | bauzas | abhishekk: thanks, wrote an email about this | |
| 08:35:10 | bauzas | (to summarize) | |
| 08:35:17 | abhishekk | yes, just went through it | |
| 08:36:35 | abhishekk | bauzas, are you sure failure is because of this warning ? | |
| 08:37:01 | bauzas | abhishekk: I'm nearly sure the test is failing because glance is returning a 502 | |
| 08:37:25 | abhishekk | ok, will have a look and get back to you | |
| 08:38:05 | bauzas | abhishekk: but I relate the glance g-api warning with the same req-id of the failing glance image upload | |
| 08:38:25 | bauzas | correlation isn't consequence, I know, but that's a starting point | |
| 08:38:33 | abhishekk | ack | |
| 08:39:17 | lyarwood | bauzas: the test is 100% failing because of the 502 it just isn't clear why g-api or httpd is returning it | |
| 08:39:27 | lyarwood | sorry got my head stuck downstream again | |
| 08:39:40 | bauzas | yup, that's what I said to abhishekk | |
| 08:39:53 | bauzas | we have an image upload failure | |
| 08:40:00 | bauzas | but we don't know why | |