Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-05-10
12:12:10 openstackgerrit Balazs Gibizer proposed openstack/nova master: Remove unused param from _fill_provider_mapping https://review.opendev.org/655107
12:12:11 openstackgerrit Balazs Gibizer proposed openstack/nova master: Move _fill_provider_mapping to the scheduler_utils https://review.opendev.org/655108
12:12:11 openstackgerrit Balazs Gibizer proposed openstack/nova master: prepare func test env for moving servers with bandwidth https://review.opendev.org/655109
12:12:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: allow getting resource request of every bound ports of an instance https://review.opendev.org/655110
12:12:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Pass network API to the conducor's MigrationTask https://review.opendev.org/655111
12:12:13 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add request_spec to server move RPC calls https://review.opendev.org/655721
12:12:13 openstackgerrit Balazs Gibizer proposed openstack/nova master: re-calculate provider mapping during migration https://review.opendev.org/655112
12:12:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: update allocation in binding profile during migrate https://review.opendev.org/656422
12:12:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: Extend NeutronFixture to handle migrations https://review.opendev.org/655114
12:12:15 openstackgerrit Balazs Gibizer proposed openstack/nova master: func test for migrate server with ports having resource request https://review.opendev.org/655113
12:47:05 artom Does placement understand AZs? Or I guess a better question would be, if we make the right request to placement (whatever that request may look like), are we guaranteed to get at least some hosts in the correct AZ?
12:48:59 amodi artom: yes, they do, https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#availability-zones-with-placement
12:49:33 artom francoisp, ^^
12:49:56 francoisp yes thanks amodi, artom
12:51:12 artom mdbooth, by the way, are we going to start including francoisp in our triage call?
12:51:48 artom Doh, wrong channel, answer downstream plz :)
13:10:49 openstackgerrit Merged openstack/nova master: Expose Hyper-V supported image types https://review.opendev.org/655137
13:37:01 openstackgerrit Arnaud Morin proposed openstack/nova master: Always Set dhcp_server in network_info https://review.opendev.org/658362
13:46:53 openstackgerrit Merged openstack/nova master: Make libvirt expose supported image types https://review.opendev.org/653454
14:50:37 efried tssurya: Quick look at https://review.opendev.org/#/c/648662/ if you please, sanity check my comment.
14:51:28 tssurya efried: checking
14:53:16 tssurya in a meeting, will answer asap
14:53:52 efried tssurya: thanks. If I'm wrong about that wrinkle, I'll happily +2 (will let mriedem approve though)
14:56:50 mriedem i think you're right, and likely need to use oneOf
14:57:02 mriedem where the options are null with no locked_reason or object with a required locked_reason
14:59:04 mriedem efried: i think it just copied how 2.56 works for cold migrate where you can specify null or a dict with a host
14:59:14 mriedem and it looks like that schema has the same issue where you can pass null or {}
14:59:33 efried woot
15:10:33 tssurya efried, mriedem: yea I basically did what 2.56 did for migrate host
15:10:54 tssurya I thought it was more of a feature thing than a bug :)
15:11:42 tssurya but maybe you are right, empty dict shouldn't be allowed ?
15:12:54 efried tssurya, mriedem: IMO there's no reason to allow it; just increases the test surface for no value.
15:13:23 efried And I guess we ought to have a test regardless.
15:13:28 tssurya efried: ack, I'll write a unit test like mriedem said and fix this then
15:13:32 efried ++
15:13:34 efried thanks tssurya
15:13:49 tssurya thanks for the detailed eyeying :)
15:14:12 efried handful of nits you can fix up while you're in there if you feel like it
15:14:48 tssurya yep
15:21:58 openstackgerrit Dongcan Ye proposed openstack/nova master: Raise BuildAbortException while updating instance task_state conflict https://review.opendev.org/633160
16:44:07 mriedem dansmith: seems our external event routing isn't working across multiple cells, the api figures out the instance is migrating and gets the proper hosts but for whatever reason only the source host gets the event...anyway, that's the current reason why the multi-cell resize stuff is failing in the gate, will have to dig a bit after lunch.
16:44:17 mriedem maybe i can assert that somehow in my functional test, not sure how though
16:46:07 dansmith hmm, maybe because of the batching to the compute api that it does
16:46:25 dansmith it tries to collate multiple events per host where possible
16:53:55 tssurya efried, mriedem: https://review.opendev.org/#/c/648662/11/nova/api/openstack/compute/schemas/lock_server.py I am not sure if its a good idea anymore because a lot of the actions don't have schema validation at all, that means they allow empty dicts and what not.
16:54:07 tssurya let me know what you guys thing when you have the time
16:55:10 tssurya think*
18:02:47 mriedem i guess i can't really do the same thing in the functional test because of the fake driver and neutron fixture
18:04:49 mriedem fried_rolls: replied to surya's comment but haven't gone through the rest of that change yet since the last time - if you are +2 please withold the +W so i can take a look through it again
18:18:56 mriedem dansmith: ah yes,
18:18:57 mriedem if host not in cell_contexts_by_host:
18:18:57 mriedem cell_contexts_by_host[host] = instance._context
18:19:03 mriedem that assumes all of the hosts are in the same cell
18:19:43 dansmith you mean, it assumes that for a given instance, the src/dst host will be in the same cell
18:19:45 dansmith yeah?
18:19:47 mriedem yup
18:20:05 dansmith is there no comment above saying "we assume..." ?
18:20:10 mriedem i can probably recreate/test that in my functional multi-cell test by just sending an event with a migration that has hosts in different cells
18:20:49 mriedem not really, but https://github.com/openstack/nova/blob/0cb1544106346664b4a53114458417ea62474b8c/nova/compute/api.py#L4853
18:20:54 mriedem i wouldn't really expect it to either
18:20:57 mriedem nothing has needed it yet
18:21:15 mriedem https://github.com/openstack/nova/blob/0cb1544106346664b4a53114458417ea62474b8c/nova/compute/api.py#L4869
18:21:23 dansmith right, but I was thinking we had discussed this before,
18:21:32 mriedem ah yes
18:21:33 mriedem Consequently we can currently assume that the context for # both the source and destination hosts of a migration is the # same.
18:21:33 dansmith and putting a comment like that seems like something you would have made me do :)
18:21:35 mriedem didn't read far enough
18:21:39 mriedem it was mdbooth
18:22:11 openstackgerrit Merged openstack/os-traits master: Update SEV trait docs to avoid misleading people https://review.opendev.org/655671
18:22:53 mriedem so if the migration record has cross_cell_move=true i'll have to tell it to pull the dest host mapping via the host mapping
18:23:06 mriedem so still optimized for the non-cross-cell case
18:23:55 dansmith cool
18:35:19 openstackgerrit Surya Seetharaman proposed openstack/nova master: Microversion 2.73: Support adding the reason behind a server lock https://review.opendev.org/648662
18:50:56 eandersson lol mriedem
18:54:33 zzzeek jaypipes: ping
18:56:08 mriedem hmm my genius test must not be so great http://paste.openstack.org/show/751238/
18:56:11 mriedem since it should fail, but doesn't
18:56:26 mriedem was hoping to avoid stubbing things out in the functional test to test the multi-cell event routing
18:57:45 mriedem dansmith: is there maybe something in our rpc fixture stuff that wouldn't make this easy to test in a functional test because we're using fake rpc?
18:58:16 dansmith mriedem: er, I wouldn't think so.. you're using the multi cell fixture?
18:58:31 mriedem yeah, my functional tests work fine for multi-cell
18:58:49 mriedem could be my context manager yield pattern in ^ isn't actually asserting anything
19:04:00 mriedem no that routing seems to be working at least on one host
19:04:01 mriedem b'2019-05-10 15:02:18,969 DEBUG [nova.compute.manager] Processing event network-vif-plugged-60c6c823-ed75-46a0-a0c6-30aadb90e78c'
19:04:01 mriedem b'2019-05-10 15:02:18,970 DEBUG [nova.compute.manager] Received event network-vif-plugged-60c6c823-ed75-46a0-a0c6-30aadb90e78c'
19:28:11 mriedem i think it works in functional testing because we're not using multiple rpc transports https://review.opendev.org/#/c/396417/
19:32:32 mriedem so i'm guessing in a multi-cell test we'd need to use per-cell rpc fixtures?
19:39:26 efried mriedem, tssurya: I'm +2 on https://review.opendev.org/#/c/648662/ - leaving for mriedem to +W.
19:45:04 mriedem oh the pressure is on
19:47:23 ganso mriedem: hey Matt. I am looking at https://review.opendev.org/#/c/658136/ ... it seems it needs https://github.com/openstack/nova/commit/94e620e87cb9349f799007f418ce94978bc33be1
19:47:42 ganso mriedem: Rocky also doesn't have the methods assertFlavorMatchesUsage and assertRequestMatchesUsage
19:48:05 ganso mriedem: do you think it makes sense to backport the refactor?
19:48:44 mriedem no
19:48:55 mriedem there should be assertion methods you can use in queens
19:51:06 ganso mriedem: only assertFlavorMatchesAllocation
19:51:13 ganso mriedem: so the solution would be to cut down on some asserts
19:57:05 mriedem without looking at the test patch, you could rig up your own usage assertion using https://github.com/openstack/nova/blob/stable/queens/nova/tests/functional/test_servers.py#L1514
19:57:17 mriedem not sure if you're asserting provider usage or consumer usage
19:57:39 mriedem i'm assuming the former
19:57:58 ganso mriedem: yup, doing that now. Basically re-coding the test to perform checks as it was done in queens

Earlier   Later