| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-24 | |||
| 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 | |
| 15:38:14 | sean-k-mooney | the closes is proabnly line 59 | |
| 15:38:31 | sean-k-mooney | but we shoudl ahve a wait before that if we were relying on it | |
| 15:39:23 | lyarwood | gibi: yeah so that's just to fail the call to detach a volume on the down compute, otherwise we'd wait for the default timeout to be hit. | |
| 15:39:52 | lyarwood | gibi: and yes it's normally a cast but thanks to castascall here we timeout | |
| 15:40:30 | gibi | lyarwood: hm so after the fix https://review.opendev.org/c/openstack/nova/+/768352 the change in the timeout is not used | |
| 15:41:08 | gibi | lyarwood: so what I see is that the _create_server fails in that test case sometimes for me locally as the scheduler calls the conductor to build the instance but the conductor takes more than 1 sec to reply | |
| 15:41:25 | lyarwood | ah yeah I see | |
| 15:41:31 | gibi | if I undertand correclty after the fix the shrinked timeout is not needed any more | |
| 15:41:36 | lyarwood | correct | |
| 15:41:52 | gibi | cool, then I will remove that to stabilize the func test on a small compute | |
| 15:42:03 | gibi | I mean on a slow node | |
| 15:42:13 | lyarwood | yup, apologies for missing that, I hadn't seen it fail anywhere like that while working on it | |
| 15:43:15 | openstackgerrit | Merged openstack/nova master: apidb: Add manage.py script https://review.opendev.org/c/openstack/nova/+/771419 | |
| 15:44:11 | gibi | lyarwood: no worries. I tend to collect a list of unstable func and unit test I see locally and time to time go thought | |
| 15:45:24 | stephenfin | lyarwood: Think you could take a quick look at this stable patch? https://review.opendev.org/c/openstack/nova/+/751240 | |
| 15:45:44 | stephenfin | Context is that it'll help a student working on openstacksdk patches for adding placement support | |
| 15:46:07 | lyarwood | stephenfin: yup looking | |
| 15:51:01 | sean-k-mooney | stephenfin: gibi lyarwood quick question https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L1483 | |
| 15:51:22 | sean-k-mooney | the dev_type filed in the db is restrited to a lenth of 8 | |
| 15:51:27 | sean-k-mooney | type-vdpa is 9 | |
| 15:51:42 | gibi | /o\ | |
| 15:51:44 | stephenfin | drop type- | |
| 15:51:47 | sean-k-mooney | so shoudl i extend the column or just sotre vdpa | |
| 15:51:56 | stephenfin | it was silly in the first place | |
| 15:52:11 | gibi | OK, that works for me the type prefix seems redundant | |
| 15:52:15 | sean-k-mooney | ya i really doubt it save any space in reality | |
| 15:52:28 | sean-k-mooney | cool ill do that so | |
| 15:52:45 | sean-k-mooney | and ya the prefix is not really useful | |
| 16:15:55 | prometheanfire | sean-k-mooney: yep, thanks :D | |