Earlier  
Posted Nick Remark
#openstack-nova - 2019-05-10
09:57:38 openstackgerrit Balazs Gibizer proposed openstack/nova master: reorder conditions in _heal_allocations_for_instance https://review.opendev.org/655458
09:57:38 openstackgerrit Balazs Gibizer proposed openstack/nova master: pull out functions from _heal_allocations_for_instance https://review.opendev.org/655457
09:57:39 openstackgerrit Balazs Gibizer proposed openstack/nova master: pull out put_allocation call from _heal_* https://review.opendev.org/655459
09:57:39 openstackgerrit Balazs Gibizer proposed openstack/nova master: Prepare _heal_allocations_for_instance for nested allocations https://review.opendev.org/637954
09:57:40 openstackgerrit Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.opendev.org/637955
11:17:13 kashyap ildikov: Hi, when you're about, do you have a minute to re-read this error message you've added in _set_multiattach_support()?
11:17:23 kashyap LOG.debug('Volume multiattach is not supported based on current '
11:17:26 kashyap 'versions of QEMU and libvirt. QEMU must be less than '
11:17:29 kashyap '2.10 or libvirt must be greater than or equal to 3.10.')
11:17:38 kashyap I think the "or" there should be "and", isn't it?
11:17:43 kashyap Otherwise, it doesn't quite resolve.
11:39:23 ildikov kashyap: I think the 'or' was intentional
11:41:02 kashyap ildikov: Hmm, in that case, I've seen someone from HP report a bug with the above error: where they have 2.10.1 QEMU and libvirt as 3.6.0.
11:41:58 openstackgerrit Balazs Gibizer proposed openstack/nova-specs master: Server move operations with ports having resource request https://review.opendev.org/652608
11:41:59 ildikov kashyap: yeah, that should lead to an error
11:42:20 ildikov kashyap: as neither the QEMU version is lower nor the libvirt version is higher than suggested
11:42:37 ildikov kashyap: it's due to how they handle caching or smth
11:43:00 ildikov as we needed to turn that off for volumes being attached to multiple instances
11:43:31 kashyap Yeah, I was reading the related code in the source. Let me go recheck
11:43:32 ildikov and there were some changes in how that's handled with the flags, etc
11:43:49 ildikov in QEMU and libvirt
11:43:56 kashyap (Hmm, but that error message is somewhat confusing.)
11:44:07 kashyap ildikov: Right, I saw the bugzilla linked which describes the mess in libvirt
11:45:18 kashyap ildikov: Oh, bad me -- I mistook 3.6.0 as higher than 3.10.0. Can I be blinder than that...
11:45:30 ildikov well, the error message only says that if the QEMU version is low enough than nothing else matters and the same thing for the libvirt one if it's high enough
11:45:51 ildikov kashyap: happens to everyone :)
11:49:41 kashyap ildikov: Thanks for the clarification. Just someone reading it out loud is just what you need sometimes :-)
11:50:27 ildikov kashyap: np, always happy to help :)
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: prepare func test env for moving servers with bandwidth https://review.opendev.org/655109
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:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Pass network API to the conducor's MigrationTask https://review.opendev.org/655111
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:13 openstackgerrit Balazs Gibizer proposed openstack/nova master: re-calculate provider mapping during migration https://review.opendev.org/655112
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:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: Extend NeutronFixture to handle migrations https://review.opendev.org/655114
12:12:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: update allocation in binding profile during migrate https://review.opendev.org/656422
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 cell_contexts_by_host[host] = instance._context
18:18:57 mriedem if host not in cell_contexts_by_host:
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 dansmith and putting a comment like that seems like something you would have made me do :)
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: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

Earlier   Later