| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-24 | |||
| 12:29:06 | sean-k-mooney | its the snapshot delete that looks like its failing | |
| 12:29:08 | sean-k-mooney | https://zuul.opendev.org/t/openstack/build/e9e69b9af21c414a83c0437894826178/log/controller/logs/screen-n-cpu.txt#48125 | |
| 12:30:26 | sean-k-mooney | : {'file_to_merge': 'volume-3c98d95e-a839-4eaf-ba76-325ed3a3a946.adb8bb67-dfb5-4ac7-8e95-3643f8a0e8ed', 'merge_target_file': 'volume-3c98d95e-a839-4eaf-ba76-325ed3a3a946', 'type': 'qcow2', 'volume_id': '3c98d95e-a839-4eaf-ba76-325ed3a3a946'} | |
| 12:30:45 | sean-k-mooney | i think file_to_merge and merge_target_file come form cinder | |
| 12:35:06 | sean-k-mooney | tosky: you could poteanally skip that on ussuri temporally i guess if its fine on other brances | |
| 12:35:27 | sean-k-mooney | it might be due to the libvirt version we are using | |
| 12:35:40 | sean-k-mooney | but this does look like there is a real bug | |
| 12:41:41 | openstackgerrit | Merged openstack/nova master: libvirt: start tracking NUMACell.socket for hosts https://review.opendev.org/c/openstack/nova/+/766816 | |
| 12:45:18 | whoami-rajat | lyarwood: sean-k-mooney https://bugs.launchpad.net/nova/+bug/1916750 | |
| 12:45:20 | openstack | Launchpad bug 1916750 in OpenStack Compute (nova) "[gate] devstack-plugin-nfs-tempest-full-ussuri job failing" [Undecided,New] | |
| 12:45:48 | sean-k-mooney | whoami-rajat: thanks | |
| 13:01:53 | tosky | whoami-rajat: thanks | |
| 13:07:47 | gibi | stephenfin, bauzas: I'm +2 through the whole api db compaction series. | |
| 13:10:29 | whoami-rajat | np | |
| 13:17:12 | stephenfin | gibi: \o/ | |
| 13:17:31 | stephenfin | Let me know if I can return the favour. I think I'm on top of most of your work | |
| 13:18:00 | gibi | stephenfin: yes, my only remaning sizeable thing is the device detach series but there I have to do fixes in the last patch | |
| 13:18:12 | sean-k-mooney | stephenfin: not sure if you saw the sqlalchemy migrate thread on the mailing list | |
| 13:18:16 | gibi | fortunatley I'm running out of code to write as the FF closes in, so I can focus on review | |
| 13:18:23 | sean-k-mooney | stephenfin: is you current db compation work just the comparction | |
| 13:18:34 | sean-k-mooney | or will you have swapped nova to almenbic this cycle | |
| 13:18:39 | gibi | just compaction | |
| 13:18:43 | sean-k-mooney | ok | |
| 13:18:56 | sean-k-mooney | since matt left no one has maintained it | |
| 13:19:28 | sean-k-mooney | gibi: so its currenly unmaintained and we need to adress that untill nova nolonger uses it | |
| 13:19:47 | stephenfin | dansmith: If you have time this week, your attention would still be appreciated on the API DB compaction series. My testing methodology was identical to the main DB | |
| 13:19:53 | gibi | sean-k-mooney: I think stephenfin could propose to move to alembic in the next cycle ;) | |
| 13:20:01 | sean-k-mooney | yep | |
| 13:20:03 | stephenfin | sean-k-mooney: I have an alembic migration series locally, but I'm not going to push it until after M3 | |
| 13:20:19 | stephenfin | We have enough work on our plates :) | |
| 13:20:21 | sean-k-mooney | http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020666.html this is the thread | |
| 13:20:39 | sean-k-mooney | stephenfin: i think the issue is oslo db deprectaed support for it | |
| 13:20:45 | stephenfin | I did that | |
| 13:21:04 | sean-k-mooney | ya so some are concerned that its un maintined and that its not deprecated in oslo | |
| 13:21:13 | sean-k-mooney | but we still have multipel project using it | |
| 13:21:41 | sean-k-mooney | as long as we dont remove oslo supprot until they are are all moved then i think its ok | |
| 13:21:55 | sean-k-mooney | maybe you could respond to the thread and clarify that | |
| 13:22:20 | stephenfin | yup, replying now. Thanks for bringing it to my attention | |
| 13:24:04 | sean-k-mooney | if there are actully bugs with sqlam i can maybe try and fix some of them. im not really that famialar with it but i can take a look if needed. | |
| 13:37:13 | bauzas | gibi: woah, you're quick | |
| 13:37:24 | bauzas | it takes me a while for reviewing a single DB change | |
| 13:37:27 | gibi | bauzas: it is a lot simpler than the db compaction | |
| 13:37:35 | gibi | mostly new tables | |
| 13:37:36 | bauzas | and I haven't started the api db ones | |
| 13:37:47 | gibi | no shadow complication | |
| 13:37:48 | bauzas | gibi: well, you're probably right | |
| 13:38:07 | bauzas | I was on the uefi secure boot series but I can churn | |
| 13:38:24 | gibi | I haven't looked at it | |
| 13:38:31 | gibi | so it is just load sharing I guess | |
| 13:39:18 | gibi | stephenfin: btw, can we remove the placement table creations from the Train db creation? or we removed placement from nova after train? | |
| 13:40:03 | stephenfin | gibi: I don't think we can remove anything without an additional migration, otherwise we'll end up with a difference between upgraded deployments and new deployments | |
| 13:40:10 | bauzas | gibi: I'm following the ghostbusters directive called 'Never cross the Beams' | |
| 13:40:32 | gibi | stephenfin: you are right, that is a new migration. nvm | |
| 13:40:44 | gibi | s/nvm/never mind/ | |
| 13:41:07 | stephenfin | Then again, I do know we have some table columns that we don't reflect in the model (something to do with vpmem, iirc) so maybe it's not totally crazy. I should discuss with dansmith next cycle | |
| 13:41:21 | bauzas | dammit s/beams/streams f'ck you French dubbing | |
| 13:41:23 | stephenfin | For now though, it's easier to keep it. There's a lot of models we need to delete | |
| 13:41:26 | stephenfin | *there are | |
| 13:41:46 | gibi | stephenfin: agree. let's do a cleanup next cylce if possible | |
| 13:42:22 | sean-k-mooney | stephenfin: ya the vpmem column was used for like 10 commits then we replaced it with a generic resouces column | |
| 13:42:39 | sean-k-mooney | we never released with it in use so you would have only used it if you deployed on master | |
| 13:42:48 | stephenfin | ah yes, that was it | |
| 13:42:52 | stephenfin | different situation so | |
| 13:42:55 | sean-k-mooney | we may have others tha were used in the past and are not now | |
| 13:43:04 | sean-k-mooney | we historically have not dropped those | |
| 13:43:10 | sean-k-mooney | but we could | |
| 13:43:19 | sean-k-mooney | we did not drop them incase you were doing FFU | |
| 13:43:34 | sean-k-mooney | but the oldest ones could likely go | |
| 13:43:40 | sean-k-mooney | or the placment related ones in the nova db | |
| 13:44:22 | stephenfin | yeah, I have patches up to remove some models but they'll need to be reworked to be alembic things | |
| 13:44:27 | stephenfin | In Xena though | |
| 13:52:34 | bauzas | I wouldn't say this series helped teenagers to grow | |
| 13:52:38 | gibi | :) | |
| 13:55:54 | dansmith | stephenfin: I've had that open for a while now and just haven't gotten to it, I'm sorry... this week has been crazy and I likely won't get to it, but will keep it in my queue | |
| 13:56:22 | stephenfin | dansmith: no worries :) | |
| 13:56:22 | dansmith | stephenfin: but, my confidence is high based on the last round, so you don't need to wait for me if others have done the due diligence | |
| 13:56:29 | stephenfin | ack | |
| 13:56:57 | stephenfin | bauzas: fwiw ^ (though I rank secure-boot slightly higher rn, in case it's between the two) | |
| 13:57:50 | bauzas | ack, reviews reviews reviews | |
| 13:58:13 | bauzas | in the middle I should take opportunity of revisiting my own RPC API change | |
| 13:58:17 | stephenfin | all the reviews! | |
| 14:04:44 | stephenfin | prometheanfire: https://review.opendev.org/c/openstack/nova/+/741351 is approved so mock 4.x should be unblocked from our side now, fwiw | |
| 14:04:52 | stephenfin | *is merged | |
| 14:14:11 | sean-k-mooney | gibi: would you have time to look at this small plamcent change https://review.opendev.org/c/openstack/placement/+/777174 | |
| 14:14:42 | sean-k-mooney | gibi: it looks like we skiped a step as part of the rescent os-traits release. | |
| 14:14:52 | gibi | looking | |
| 15:03:46 | jkulik | hm ... is there a mechanism to clean up lingering build-requests? We seem to have a couple still around ... | |
| 15:14:17 | sean-k-mooney | jkulik: i belive they shoudl be cleaned up when the instance exits teh build status | |
| 15:14:43 | sean-k-mooney | so if they are lingering you proably have vms stuck in build or you have deleted them and we did not clean up properly | |
| 15:14:55 | sean-k-mooney | jkulik: do you know which is the case? | |
| 15:15:11 | jkulik | I cannot find them in any cell DB. I assume they never made it there. | |
| 15:17:55 | jkulik | so probably network problems at the time. if there's no automatic mechanism, we have to clean them manually before upgrading to rocky | |
| 15:18:13 | jkulik | they're missing the "trusted_certs" attribute and thus make server listing fail with an HTTP 500 | |
| 15:33:26 | gibi | lyarwood: do you remember why the rpc_response_timeout=1 is needed in https://review.opendev.org/c/openstack/nova/+/768351/2/nova/tests/functional/regressions/test_bug_1909120.py#31 ? That test case sometimes fails to me locally with http://paste.openstack.org/show/802963/ and I try to figure out why | |
| 15:34:52 | sean-k-mooney | gibi: hum maybe it was jus tto have it time out quickly | |
| 15:34:53 | gibi | wondering if what happens is that the timeout is enforced even if we have castAsCall used, and the actual call takes longer than 1 sec | |
| 15:35:48 | sean-k-mooney | looking at it quickly im not sure. settign it to like 5s or 10 likely is ok | |
| 15:36:59 | sean-k-mooney | we should not really be relying on that for timing anyway | |
| 15:37:22 | gibi | I don't see where it in the test helps if an rpc times out early | |
| 15:37:28 | gibi | hence my question | |