| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-17 | |||
| 17:57:06 | efried | Let me put it this way: what would the reno say? | |
| 17:57:11 | sean-k-mooney | so this is just passign the ovs datapath type wich we have in teh vif to os-vif | |
| 17:57:15 | efried | What will the user notice? | |
| 17:58:25 | sean-k-mooney | opereators will now by able to deploy ovs-dpdk with hardwar offloads for nvf/telco deployment that need hi data rates and a fast fallback path when a feature is not supported in hardware | |
| 17:59:13 | sean-k-mooney | we could skip the reno i guess but it would be nice to call this out in 1 of nova, os-vif or neutron | |
| 17:59:31 | sean-k-mooney | the patch to enable it in all 3 repos are equally short however | |
| 18:00:20 | efried | sean-k-mooney: Okay, so a bug definitely doesn't seem appropriate; it sounds like a feature to me. | |
| 18:00:28 | sean-k-mooney | this prettymuch almost works already | |
| 18:00:46 | sean-k-mooney | ya i was thinking that too but its also a tiny change | |
| 18:00:55 | sean-k-mooney | hence sepcless blueprint | |
| 18:00:58 | efried | Right, so if it's truly tiny, a specless blueprint would be fine. | |
| 18:01:00 | efried | imo | |
| 18:01:17 | sean-k-mooney | well that patch is the total cahnge needed to nova | |
| 18:01:21 | efried | what would the operator need to do to make things happen? | |
| 18:01:29 | efried | (is the kind of thing I would want the bp to say) | |
| 18:01:39 | efried | is there an API change? | |
| 18:02:02 | efried | configs that affect? | |
| 18:02:05 | efried | docs that need to be updated? | |
| 18:02:07 | sean-k-mooney | just install ovs-dpdk on a host with a melonox nic that support hardware offloand and have the right version of nova and neutron | |
| 18:02:23 | sean-k-mooney | there is not api change or change to iamge or flaovr | |
| 18:02:46 | sean-k-mooney | you use the feature the same way as hardware offloaded kernel ovs | |
| 18:03:04 | openstackgerrit | Adam Spiers proposed openstack/nova master: Extract SEV-specific bits on host detection https://review.opendev.org/636334 | |
| 18:03:19 | sean-k-mooney | i am not sure if we have docs for that but assuming we do the might want to be updated | |
| 18:03:37 | efried | neat. So yeah, a specless blueprint sounds appropriate to me. Though I guess the problem is that you can't file a single blueprint against multiple projects? | |
| 18:03:40 | aspiers | ALL YOUR REBASE ARE BELONG TO US | |
| 18:03:49 | sean-k-mooney | efried: https://docs.openstack.org/neutron/rocky/admin/config-ovs-offload.html shoudl be updated | |
| 18:03:58 | sean-k-mooney | but that is in neutron | |
| 18:04:16 | aspiers | that's probably the best joke I ever made </tragically_proud_moment> | |
| 18:04:28 | sean-k-mooney | efried: yep which is why i was questioning should it be an rfe bug | |
| 18:04:33 | efried | aspiers: Cause you know I'm all about rebase, 'bout rebase... | |
| 18:04:49 | efried | sean-k-mooney: Is that a thing? Then sure. | |
| 18:04:49 | sean-k-mooney | but specless blueprint for nova and rfe bugs that is shared for os-vif/nueton is fine too | |
| 18:04:51 | aspiers | damn, instantly upstaged, just like that | |
| 18:05:03 | sean-k-mooney | efried: its what neutron uses for all feature requests | |
| 18:05:11 | efried | heh, okay. | |
| 18:05:14 | efried | wfm | |
| 18:05:15 | sean-k-mooney | we dont use rfe bugs in nova | |
| 18:05:29 | sean-k-mooney | its litrally just a rfe tag on the bug | |
| 18:06:01 | sean-k-mooney | cool anyway really going this time o/ | |
| 18:07:14 | aspiers | haha the number of times I've said that | |
| 18:08:39 | artom | aspiers, you have no chance to survive, merge your time | |
| 18:10:41 | aspiers | artom: somebody set up us the branch | |
| 18:11:22 | artom | aspiers, move TAG | |
| 18:11:54 | aspiers | CI was beginning | |
| 18:12:09 | aspiers | We get review | |
| 18:12:33 | aspiers | You are on the way to -2 | |
| 18:12:50 | aspiers | What you say !! | |
| 18:13:56 | artom | You've gone and rewritten the story. | |
| 18:14:00 | aspiers | :D | |
| 18:14:06 | artom | Not just random puns, a coherent narrative | |
| 18:14:40 | aspiers | I try my best | |
| 18:16:25 | artom | You definitely know what you doing. | |
| 18:17:04 | aspiers | For great fun | |
| 18:17:41 | aspiers | OK, I think it's time for the weekend | |
| 18:17:44 | aspiers | Main screen turn off | |
| 18:31:44 | openstackgerrit | Adam Spiers proposed openstack/nova master: Add |
|
| 18:37:45 | efried | aspiers: https://review.opendev.org/#/c/638680/ reviewed, lemme know if we need to Talk. | |
| 18:41:28 | aspiers | efried: looking | |
| 18:41:50 | aspiers | totally fell into the same trap as sean-k-mooney | |
| 18:42:11 | aspiers | Main screen did not turn off :-/ | |
| 18:46:42 | openstackgerrit | Adam Spiers proposed openstack/nova master: Add detection of SEV support from QEMU/AMD-SP/libvirt on AMD hosts https://review.opendev.org/633855 | |
| 18:52:15 | aspiers | efried: thanks, makes sense to move it to u_p_t() | |
| 18:52:18 | aspiers | I'll do that next week | |
| 18:54:21 | efried | cool, thanks. | |
| 18:55:28 | aspiers | efried: so that would mean it's no longer called from init_host(), right? | |
| 18:57:13 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Use OpenStack SDK for placement https://review.opendev.org/656023 | |
| 18:57:13 | openstackgerrit | Eric Fried proposed openstack/nova master: Introduces the openstacksdk to nova https://review.opendev.org/643664 | |
| 18:57:48 | openstackgerrit | Eric Fried proposed openstack/nova master: Introduces the openstacksdk to nova https://review.opendev.org/643664 | |
| 18:57:49 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Use OpenStack SDK for placement https://review.opendev.org/656023 | |
| 19:00:36 | aspiers | ComputeManager.pre_start_hook() -> .update_available_resource() -> ._update_available_resource_for_node() -> ResourceTracker.update_available_resource() -> ._update_available_resource() -> ._update() -> ._update_to_placement() -> driver.updated_provider_tree() | |
| 19:01:28 | aspiers | efried: but it seems that there are many other code paths which could reach update_provider_tree(), so your previous question about locking of the region modifying _domain_caps now will have a different answer | |
| 19:02:10 | efried | aspiers: I don't have a problem with the call chain through init_host as you've currently got it setting *some* instance variable on the libvirt driver. | |
| 19:02:14 | efried | which upt can then just go read | |
| 19:02:17 | aspiers | although ResourceTracker._update_available_resource has a semaphore, so maybe that's OK anyway? | |
| 19:02:27 | efried | it just shouldn't be in the capability dict. | |
| 19:02:44 | aspiers | OK, just wondering where's the best place to put it | |
| 19:03:00 | efried | self._supports_sev | |
| 19:03:02 | efried | whatever | |
| 19:03:07 | aspiers | yeah I guess the way you suggest works | |
| 19:03:36 | efried | you can put a comment saying we do this during init_host for efficiency and because it doesn't change | |
| 19:03:55 | aspiers | right - if I put it in resource_tracker.py then it would probably get called too often (i.e. more than once) | |
| 19:04:31 | efried | right. And the singleton-ness you've got set up on it would partially mitigate that - but there's no reason to even have the extra call stacks in the way. | |
| 19:04:44 | efried | memoizing, not singleton | |
| 19:04:58 | aspiers | yep | |
| 19:05:28 | efried | how's that whole stopping-working-because-it's-eod-friday thing going for you? | |
| 19:05:44 | aspiers | really great, just fantastic | |
| 19:06:16 | efried | You got a taste for it in Denver, now you can't get enough. | |
| 19:07:24 | aspiers | sad but true | |
| 19:23:05 | openstackgerrit | Eric Fried proposed openstack/nova stable/stein: Skip _exclude_nested_providers() if not nested https://review.opendev.org/659206 | |
| 19:23:05 | openstackgerrit | Eric Fried proposed openstack/nova stable/stein: DNM: Revert "Use external placement in functional tests" https://review.opendev.org/659682 | |
| 19:25:23 | aspiers | efried: last question before I go, you're saying that I don't need a driver capability at all, and u_p_t() would just provide the trait directly? | |
| 19:25:37 | efried | aspiers: Correct | |
| 19:25:46 | aspiers | OK good, thought so | |
| 19:25:54 | efried | aspiers: From the operator's point of view: | |
| 19:26:05 | efried | if they want mem encryption, they request resource MEM_ENCRYPTION_CONTEXT=1 | |
| 19:26:13 | efried | if they want SEV specifically, they request required=SEV | |
| 19:26:15 | aspiers | BTW the kernel module parameter file is readable non-root, so I'm assuming privsep not required | |
| 19:26:23 | aspiers | right | |
| 19:26:24 | efried | okay. | |
| 19:26:46 | aspiers | IIRC, what you just wrote is captured in the spec | |