| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-22 | |||
| 12:26:55 | openstackgerrit | Michal Arbet proposed openstack/nova master: Fix python3 compatibility of rbd get_fsid https://review.openstack.org/635220 | |
| 12:38:46 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: Clarify upgrade situation in NUMA live migration https://review.openstack.org/638653 | |
| 12:38:50 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Remove _legacy_dict methods https://review.openstack.org/636210 | |
| 12:38:50 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Add migration param to check_can_live_migrate_destination https://review.openstack.org/634605 | |
| 12:38:51 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Introduce live_migration_claim() https://review.openstack.org/635669 | |
| 12:38:51 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Use live_migration_claim() to check dest resources https://review.openstack.org/634606 | |
| 12:38:52 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: New objects to transmit NUMA config from dest to source https://review.openstack.org/634827 | |
| 12:38:52 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: Make dest send NUMAMigrateData to the source https://review.openstack.org/634828 | |
| 12:38:53 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: update NUMA-related XML on the source https://review.openstack.org/635229 | |
| 12:38:53 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP] Drop MoveClaim in rollback_live_migration_at_destination https://review.openstack.org/638654 | |
| 13:37:57 | mriedem | giblet: some questions in https://review.openstack.org/#/c/569459/ | |
| 13:41:33 | giblet | mriedem: thanks, I will check it soon | |
| 13:42:01 | giblet | mriedem: I've also looked into the Selection object usage instead of querying placement about allocations. It is easy so I will push a fup | |
| 13:42:27 | giblet | mriedem: I also thinking about storing the provider_summaries in the Selection object to avoid the trait query as well | |
| 13:42:49 | giblet | it is a bit more code as it needs a version bump on the Selection object | |
| 13:44:41 | mriedem | giblet: yeah that's why in my fup i said short-term optimization (cache) and long-term (provider summary traits -> Selection object) | |
| 13:45:25 | mriedem | giblet: as for reading the allocations off the Selection.allocation_request, jaypipes did warn yesterday that if that request format changes, it could break your code (but we have the version of the format so i guess we could deal with that when the time comes, if it comes) | |
| 13:45:38 | mriedem | today the allocation request mirrors the response, which was a smart move looking back (thanks cdent) | |
| 13:46:30 | openstackgerrit | Adam Spiers proposed openstack/nova master: Add detection of SEV support from QEMU/AMD-SP/libvirt on AMD hosts https://review.openstack.org/633855 | |
| 13:46:31 | cdent | don't that me, thank "HTTP API BEST PRACTICES"... or something | |
| 13:46:34 | openstackgerrit | Merged openstack/nova stable/queens: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/620578 | |
| 13:46:36 | giblet | mriedem: noted the possible format change. I can put a NOTE to the allocation_request field definition to warn the future developer | |
| 13:46:44 | openstackgerrit | Merged openstack/nova stable/queens: tox: Don't write byte code (maybe) https://review.openstack.org/636918 | |
| 13:48:07 | mriedem | kashyap: this looks like a new one for the gate http://logs.openstack.org/48/631948/9/check/tempest-full-py3/e2ae3fb/controller/logs/screen-n-cpu.txt.gz?level=TRACE#_Feb_21_17_24_48_562689 | |
| 13:48:43 | giblet | mriedem: will there be separate Selection object for each instance created in the same multi-create request? or in other words can I use a non ovo field on the Selection object as a trait cache? | |
| 13:49:15 | mriedem | selections are 1:1 with the requested instances we're building yes | |
| 13:49:38 | mriedem | because the 10th instance in the request could have a different primary and alternate hosts b/c the first 9 consumed all of the resources on some other hosts | |
| 13:49:41 | giblet | mriedem: OK, then I need a separate cache | |
| 13:50:08 | mriedem | yeah - there are already some caches used in schedule_and_build_instances | |
| 13:50:14 | mriedem | for host mappings and az queries | |
| 13:50:36 | giblet | mriedem: ahh I see. That is a pattern I can follow | |
| 13:51:57 | giblet | mriedem: do we handle re-schedule during multi-create in a special way or is it the same re-schedule code path? We have to call _fill_provider_mapping for the re-schedule too | |
| 13:52:39 | mriedem | same as single instance | |
| 13:52:48 | mriedem | the reschedule just gets 1 instance | |
| 13:52:57 | mriedem | a list of 1 i should say | |
| 13:53:23 | mriedem | that is rpc cast from compute here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2024 | |
| 13:53:52 | giblet | mriedem: then the cache would not work for re-schedule but the Selection object based soluton would work as re-schedule gets the Selection object too | |
| 13:54:15 | mriedem | we don't need the cache for reschedule since it's 1 instance | |
| 13:54:21 | mriedem | the cache is more for multi-create | |
| 13:54:48 | mriedem | but yeah again, short and long term optimizations | |
| 13:54:58 | giblet | if half of a multi-create hit the same faulty compute then we got a bunch of re-schedule at the same time | |
| 13:55:28 | giblet | but anyhow I will do a local cache for Stein as time is sort | |
| 13:55:34 | mriedem | exactly | |
| 13:55:48 | giblet | mriedem: thanks for the help! | |
| 13:55:48 | mriedem | Selection object change to stash the traits will be an rpc change | |
| 13:55:53 | mriedem | np | |
| 13:56:08 | giblet | mriedem: good point about the rpc change. I don't want to start that 2 weeks before FF | |
| 13:56:22 | mriedem | and i dont want to have to think about it right now either :) | |
| 13:58:40 | giblet | mriedem: mentioning RPC change. Does the extension of InstancePCIRequest ovo also needs an rpc bump, here? https://review.openstack.org/#/c/625310/23 | |
| 13:59:17 | mriedem | the object version bump is the rpc change | |
| 13:59:55 | giblet | mriedem: then we still have this rpc change in the bandwidth series unfortunately | |
| 14:00:20 | mriedem | sure i think that's fine - it's at least code you've already tested / demo'ed yeah? | |
| 14:00:32 | mriedem | i'd like to avoid *new* complexity with 2 weeks left | |
| 14:01:28 | giblet | mriedem: I've tested that code in the functional env. Not demoed yet as that code was not ready for the last demo in Berlin | |
| 14:02:32 | giblet | I agree to avoid new complexity added. heal allocation is still not finished and that has its own complexity | |
| 14:03:09 | giblet | I need to run some downstream errands, brb | |
| 14:10:52 | mriedem | dansmith: you want to make sure this is ok https://review.openstack.org/#/c/636210/ - i think it's just removing dead code at this point | |
| 14:15:11 | aspiers | mriedem, efried: the capabilities patch makes adding an SEV capability extremely easy! in case you're curious: https://github.com/aspiers/nova/commit/sev-trait | |
| 14:15:28 | aspiers | I can't submit to Gerrit yet because it depends on two patches which are not dependent on each other | |
| 14:27:24 | mriedem | cool, that's kind of the idea | |
| 14:27:36 | mriedem | you could break that down by moving the capabilities to the driver instance level rather than the class | |
| 14:27:49 | mriedem | i think that would fix an issue i had in libvirt driver tests with the multiattach stuff | |
| 14:28:02 | aspiers | isn't that what I did? | |
| 14:28:22 | mriedem | you did, but in the same patch that adds the amd sev capability | |
| 14:28:30 | mriedem | anyway nvm | |
| 14:28:34 | aspiers | oh, in a separate patch | |
| 14:28:37 | aspiers | yeah, I did wonder about that | |
| 14:28:46 | aspiers | happy to split it out! if you think it's worth it | |
| 14:29:30 | mriedem | it's fine to leave it | |
| 14:29:33 | aspiers | I'll do it :) | |
| 14:29:47 | aspiers | ah, I remember my thinking now | |
| 14:29:59 | aspiers | this is only required for drivers with dynamic capabilities, right? | |
| 14:30:22 | aspiers | but I missed the fact that multiattach is already dynamic | |
| 14:30:48 | aspiers | smaller patches -> easier quicker reviews | |
| 14:30:53 | aspiers | so I'll do it | |
| 14:37:13 | openstackgerrit | Merged openstack/nova master: Follow up for I0c764e441993e32aafef0b18049a425c3c832a50 https://review.openstack.org/638517 | |
| 14:39:31 | aspiers | mriedem: done https://github.com/aspiers/nova/compare/sev-deps...aspiers:sev-trait | |
| 14:40:54 | mriedem | aspiers: so why are these in github and not gerrit? | |
| 14:41:22 | aspiers | mriedem: because they depend on two unmerged patches which are not dependent on each other | |
| 14:41:23 | mdbooth | lyaaaaarwood: I think this needs a refactor into a separate test class: https://review.openstack.org/#/c/637527/ | |
| 14:41:39 | aspiers | mriedem: so I can't submit them in a series, because that would introduce an artificial dependency | |
| 14:42:14 | aspiers | and AFAIK Depends-On is only for cross-repo dependencies | |
| 14:42:39 | mriedem | what are the other 2 patches? | |
| 14:43:02 | aspiers | https://review.openstack.org/#/c/538498/ and https://review.openstack.org/#/c/633855/ | |
| 14:43:06 | aspiers | they are mentioned in the commit message | |
| 14:43:08 | sean-k-mooney | aspiers: it works withing the same repo too but when its in teh same repo it makes more sense to rebase on top of the patch | |
| 14:43:17 | mriedem | aspiers: your sev stuff can be rebased on top of https://review.openstack.org/#/c/538498/ yes? | |
| 14:43:20 | aspiers | sean-k-mooney: agreed | |
| 14:43:27 | mdbooth | aspiers: The practical solution is to have the artificial dependency. | |
| 14:43:43 | mriedem | yeah i'd just stack these all up | |
| 14:43:46 | mriedem | with https://review.openstack.org/#/c/538498/ at the bottom | |
| 14:43:52 | aspiers | mriedem, mdbooth: OK I'm totally fine with that if you guys are, thanks | |
| 14:43:56 | mriedem | and then https://review.openstack.org/#/c/633855/ | |
| 14:44:01 | mriedem | and then the stuff that sets the capability | |
| 14:44:07 | aspiers | yup | |
| 14:44:25 | aspiers | will do now | |
| 14:45:18 | dansmith | mriedem: done | |
| 14:45:27 | mdbooth | aspiers: If you find that a patch which isn't on the bottom gets +2s you can always rebase it to the bottom. If it's a clean rebase you'll retain the +2s and it can merge. | |
| 14:45:40 | aspiers | mdbooth: nice tip, thanks | |
| 14:45:52 | mdbooth | aspiers: It's not great, but it's kinda ok and doesn't usually come up that much. | |