Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-12-10
19:32:25 mriedem if those are meant to be 1:1 then we need a test that asserts they are
19:32:33 mriedem efried_afk: sean-k-mooney: ^
19:32:54 mriedem "# NOTE(takashin): If fields are not set in the ImageMetaProps object,
19:32:55 mriedem # it will not set the fields in the ImageMetaPropsPayload
19:32:55 mriedem # in order to avoid too many fields whose values are None."
19:34:13 mriedem seems ImageMetaPropsPayload, or what uses it, would have been better off with a simple DictOfStrings thing where the values are the coerced ImageMetaProps
19:34:19 mriedem because keeping that all 1:1 seems a bit nuts
19:35:40 mriedem https://review.opendev.org/#/c/482629/
19:36:23 mriedem the request spec payload is not as beefy but it's....beefy
19:36:27 mriedem lite beef
19:41:18 mriedem dansmith: are you aware of any poison fixtures off the top of your head for the api db? like say i want to do some stuff in a test, then nuke the api db global conf connection and run some more test code
19:42:01 dansmith mriedem: no, since it requires using the fixture, I don't think we've ever needed one
19:42:13 dansmith needs the actual fixture for the api db I mean
19:42:23 mriedem wanted to test a 'no upcall' kind of thing
19:42:37 dansmith I imagine you could add something to the db fixture to let you break it midway if that's what you're tryingto do
19:44:01 mriedem i was able to do something by just getting a handle to the api db fixture and calling cleanup() on it which drops the schema on the db
19:44:15 mriedem so you get DBNonExistentTable rather than like DBConnectionError or whatever
19:44:26 mriedem might be good enough for what i need
19:47:31 dansmith yeah, that's what I was thinking
20:12:02 sean-k-mooney mriedem: ya so i think it was added as part of the version notification work
20:12:13 sean-k-mooney but it has to be manually updated each time
20:14:50 sean-k-mooney mriedem: so should i keep the payload notificion updates in the patch. i could post something to the mailing list if we want to change this longer term
20:16:10 mriedem fun https://bugs.launchpad.net/nova/+bug/1855927
20:16:10 openstack Launchpad bug 1855927 in OpenStack Compute (nova) "_poll_unconfirmed_resizes may not retry later if confirm_resize fails in API" [Low,New]
20:16:25 mriedem sean-k-mooney: idk, ask gibi
20:17:00 mriedem you get one shot at confirming a resize and if it fails you can't retry
20:17:05 mriedem without db surgery
20:18:39 sean-k-mooney oh interesting.
20:20:21 sean-k-mooney would it be valid to include both finished and confiming migration in the periodic
20:20:39 mriedem maybe
20:20:48 mriedem that doesn't change the api behavior though - you'd have to do the same in the api
20:21:08 mriedem i think like an instance task_state you likely need to reset the migration status on error
20:21:09 sean-k-mooney true
20:22:22 sean-k-mooney i can see the logic of rolling back the migration to the finished state but we dont want to keep retrying forever
20:22:52 sean-k-mooney if we go to error can we reset teh migration status to finished via the api or only via the db
20:22:59 mriedem only the db
20:23:03 mriedem there is no api to update migration records
20:24:15 mriedem it's an extremely latent bug so not high priority, just something i noticed while writing a test around that periodic
20:25:31 sean-k-mooney right /os-migrations is just a list of all migration and the server migration enpoint does not have a put
20:30:27 sean-k-mooney we check for both finished and confriming here https://github.com/openstack/nova/blob/5a3ef39539ca112ae0552aef5cbd536338db61b7/nova/compute/manager.py#L4267 do we arrive at that form finished from teh periodic task
20:30:41 mriedem yes
20:30:51 sean-k-mooney ah ok
20:31:01 mriedem https://github.com/openstack/nova/blob/5a3ef39539ca112ae0552aef5cbd536338db61b7/nova/compute/manager.py#L8866
20:31:20 mriedem the periodic on the dest host calls the api method which calls confirm_resize on the source host
20:32:08 sean-k-mooney right but the compute api method set it to confirming https://github.com/openstack/nova/blob/5a3ef39539ca112ae0552aef5cbd536338db61b7/nova/compute/api.py#L3684
20:32:19 mriedem correct
20:32:42 mriedem and after the api does that, if anything fails you can't re-confirm the resize
20:34:22 sean-k-mooney yes but in the compute manager do_confirm_resize which is an inner function of confirm_resize seams to exepct the migration could be in finished or confriming so i was trying to figure out when could it be finish since i think it shoudld only be in confirming based on that code flow
20:34:54 sean-k-mooney anyway its proably not important i just thought it was odd
20:35:04 mriedem it's probably leftover
20:35:19 mriedem or when deleting a resized server
20:35:28 mriedem see _confirm_resize_on_deleting
20:36:25 sean-k-mooney oh so we clean up the resouce on the source node then delete it on the dest
20:37:02 mriedem yes
20:38:13 sean-k-mooney that still calls confirm_resize via rpc but ya it looks like it " for status in ('finished', 'confirming'):" code was copied between the two functions
20:41:44 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: debug cross-cell resize https://review.opendev.org/698304
20:41:45 openstackgerrit Matt Riedemann proposed openstack/nova master: Add cross-cell resize tests for _poll_unconfirmed_resizes https://review.opendev.org/698322
22:02:45 openstackgerrit sean mooney proposed openstack/nova master: support pci numa affinity policies in flavor and image https://review.opendev.org/674072
22:25:21 efried well that took rather longer than expected.
22:25:59 efried sean-k-mooney: So I guess the right thing here is to hold off making irreversible OVO changes until we can get the word from gibi_off. Can you live with that?
22:26:14 sean-k-mooney yep that is fine with me
22:26:19 sean-k-mooney i address some of your nits
22:26:36 sean-k-mooney but i have not done the functional test changes yet
22:29:22 efried okay
22:30:13 sean-k-mooney do you want the extra functional test in the same patch or a follow up. i need to think about how to do it smartly instead of just copy pasting and tweeking
22:34:51 efried sean-k-mooney: stephenfin isn't disappearing until well after you do, so getting his re+2 ought to be easy enough; same patch seems reasonable.
22:35:15 openstackgerrit sean mooney proposed openstack/nova master: fix imports of typeing module https://review.opendev.org/698334
22:35:30 efried we may not even be able to move on it until the new year -- not sure whether gibi is thoroughly gone until then.
22:35:33 sean-k-mooney i think artom is going to pick up the patch if its not reay before i do
22:36:13 sean-k-mooney hum ok that would less then ideal but ok
22:36:41 sean-k-mooney i could split the notifciation change into a second patch if that helped
22:37:37 sean-k-mooney anyway im done for today so that is tommorows problem
22:37:40 sean-k-mooney night o/
22:37:59 efried yeah, let's talk again about this tomorrow, hopefully I'll have a clearer head too.
22:44:33 efried dansmith, sean-k-mooney, mriedem: FYI the cinder use of external events appears sane https://opendev.org/openstack/cinder/src/branch/master/cinder/compute/nova.py#L145
22:45:16 efried uhm
22:45:17 efried actually no
22:45:55 efried it should be setting response_error=True on L168
22:47:55 efried So that's actually a latent bug
22:49:36 efried Previously it would have triggered if they were extending volumes attached to multiple instances and a subset failed;
22:49:36 efried With our fix it would also trigger if they were extending volumes attached to one or more instances and all failed.
22:50:37 efried in this case the bug is simply that they wouldn't send the error through their messaging API.
22:55:22 mriedem rain hell fire upon them
22:57:40 efried I'm doing so in -cinder
23:28:49 efried ...and neutron is okay https://opendev.org/openstack/neutron/src/branch/master/neutron/notifiers/nova.py#L244
23:28:49 efried They're just using the codes to print log messages, and they're doing it correctly.
23:29:35 efried and those are all the relevant hits
23:30:13 efried FYI I opened https://bugs.launchpad.net/cinder/+bug/1855940 and put up https://review.opendev.org/698340 in cinder.
23:30:13 openstack Launchpad bug 1855940 in Cinder "Messages sometimes not sent when nova fails to accept "extend volume" events" [Undecided,In progress] - Assigned to Eric Fried (efried)
23:30:21 efried and with that... o/
#openstack-nova - 2019-12-11
01:13:46 openstackgerrit Merged openstack/nova master: Tie requester_id to RequestGroup suffix https://review.opendev.org/696946
02:30:47 openstackgerrit jichenjc proposed openstack/nova master: libvirt: avoid cpu check at s390x arch https://review.opendev.org/696228
02:45:20 openstackgerrit hutianhao27 proposed openstack/nova master: Revert "nova shared storage: rbd is always shared storage" https://review.opendev.org/682523
03:55:12 openstackgerrit hutianhao27 proposed openstack/nova master: Revert "nova shared storage: rbd is always shared storage" https://review.opendev.org/682523
06:25:45 openstackgerrit Merged openstack/nova master: Switch to uses_virtio to enable iommu driver for AMD SEV https://review.opendev.org/696697
06:25:53 openstackgerrit Merged openstack/nova master: Also enable iommu for virtio controllers and video in libvirt https://review.opendev.org/684825
07:18:46 openstackgerrit Shilpa Devharakar proposed openstack/nova master: Handle new is_volume_backend join column query https://review.opendev.org/694462
07:18:47 openstackgerrit Shilpa Devharakar proposed openstack/nova master: Instance object changes for the new 'is_volume_backed' expected_attr https://review.opendev.org/694463
07:18:48 openstackgerrit Shilpa Devharakar proposed openstack/nova master: Ignore root_gb if instance is booted from volume https://review.opendev.org/612626
07:47:04 gibi reading the notification while I was away I feel like IRC's away message system doesn't work as intended as I noted there that I back on Wednesday but it seems this info was unknown for the folks on the channel

Earlier   Later