| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-24 | |||
| 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 | |
| 16:16:07 | prometheanfire | stephenfin: meant that for you about the mock thing :D | |
| 17:52:35 | openstackgerrit | Clark Boylan proposed openstack/nova master: DO NOT MERGE testing a thing https://review.opendev.org/c/openstack/nova/+/777444 | |
| 18:00:49 | lyarwood | gibi: https://blueprints.launchpad.net/nova/+spec/ephemeral-storage-encryption - I've moved this to Deferred, not sure if that's the correct state but I'm punting it to at least X, I'll document why upstream next week once I'm back from PTO. | |
| 18:01:36 | openstackgerrit | Clark Boylan proposed openstack/nova master: DO NOT MERGE testing a thing https://review.opendev.org/c/openstack/nova/+/777444 | |
| 18:01:37 | gibi | lyarwood: thanks for that | |
| 18:01:52 | gibi | lyarwood: right now Deferred is OK, I will do the cleanup after FF anyhow | |
| 18:02:07 | lyarwood | gibi: ack cool | |
| 18:20:18 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove short call timeout from func test https://review.opendev.org/c/openstack/nova/+/777447 | |
| 18:20:56 | gibi | lyarwood: a small fix for the func test we talked about ^^ | |
| 19:06:47 | gregwork | can nova flavors be created that have multiple ephemeral disks? | |
| 19:06:59 | gregwork | i know you can nova boot --ephemeral x --ephemeral y | |
| 19:07:35 | gregwork | trying a nova flavor-create --ephemeral x --ephemeral y doesn't respect this via the CLI | |
| 19:13:12 | sean-k-mooney | gregwork: yes and no | |
| 19:13:24 | sean-k-mooney | you can have multiple ephmeral disk | |
| 19:13:36 | sean-k-mooney | i dont think you can spcify that in the flavor | |
| 19:13:52 | sean-k-mooney | i think you specify that durign instance creation | |
| 19:14:21 | sean-k-mooney | there is quite an obsucre way to do this ill see if i can find it but its not commonly used as far as i am aware | |
| 19:15:06 | sean-k-mooney | ok not that obscure | |
| 19:15:08 | sean-k-mooney | ova boot --flavor test-flavor --image cirros --nic net-name=test-network --ephemeral size=1,format=ext4 --ephemeral size=2,format=ext4 test-vm | |
| 19:15:34 | gregwork | so pick whatever flavor and just boot it with whats needed | |
| 19:15:35 | sean-k-mooney | gregwork: but basically the amount of space in the flavor can be subdevied during boot | |
| 19:15:54 | gregwork | oh | |