| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-10 | |||
| 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: 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 | |