| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-14 | |||
| 13:48:47 | mdbooth | Incidentally, this specific issue breaks the '1 task at a time' guard in n-api for all operations which use task state, which is nearly all of them. | |
| 13:49:00 | mdbooth | s/all operations/all instance operations/ | |
| 13:51:16 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: [Trivial doc change] Admin can overwrite the locked_reason of an owner https://review.opendev.org/659067 | |
| 13:56:42 | kashyap | aspiers: You okay with the "plan" at the end here: https://review.opendev.org/#/c/655193/ | |
| 13:57:11 | kashyap | alex_xu: If later we decide that we "really need it", we can always restore it. | |
| 14:01:15 | kashyap | efried: When you're about, bike-shedding, for the file name in 'os-traits': how about the x86.py --> x86-common.py? (Or is it "implied"?) | |
| 14:03:26 | efried | kashyap: We can't change x86.py at this point. And yes, I think common is implied. I would just make an x86 subdirectory with intel.py and amd.py | |
| 14:03:39 | kashyap | (Oh, right.) | |
| 14:03:49 | kashyap | I keep forgetting that "can't ever change" aspect. | |
| 14:03:51 | kashyap | Thx. | |
| 14:04:29 | efried | kashyap: I'm actually not 100% sure of the mechanics. I think you may have to remove x86.py and move the contents to x86/__init__.py | |
| 14:04:47 | efried | It's the strings that get produced that aren't allowed to change. | |
| 14:05:05 | kashyap | Right, I'm not sure either. I'll duke around a bit. This is my first time tipping toes into this repo | |
| 14:05:32 | kashyap | (Trying not to boil any lakes as "first steps" :D) | |
| 14:07:13 | sean-k-mooney | why woudl you move them to __init__.py | |
| 14:07:31 | sean-k-mooney | just to not have to type x86 | |
| 14:08:13 | kashyap | sean-k-mooney: I don't know, having x86.py file and x86/ directory in the _same_ directory feels "clumsy". | |
| 14:08:29 | sean-k-mooney | from a general style point of view is strongly dislike haveing __init__.py contain any content ever | |
| 14:08:37 | kashyap | sean-k-mooney: I can live with it; but open to any approach that lets us avoid it | |
| 14:09:11 | sean-k-mooney | we dont currently have an x86 direcotry correct | |
| 14:09:31 | sean-k-mooney | https://github.com/openstack/os-traits/tree/master/os_traits/hw/cpu | |
| 14:09:42 | sean-k-mooney | we just have the x86.py | |
| 14:09:51 | sean-k-mooney | why are you creating a directory | |
| 14:10:09 | kashyap | sean-k-mooney: See the discussion on the change here: https://review.opendev.org/#/c/655193/ | |
| 14:11:14 | kashyap | sean-k-mooney: Specifically this remark from Eric on PS2: | |
| 14:11:15 | kashyap | hw/cpu/x86.py (common to both Intel and AMD) | |
| 14:11:15 | kashyap | hw/cpu/x86/amd.py (AMD-specific) <== new (but see below) | |
| 14:11:15 | kashyap | hw/cpu/x86/intel.py (Intel-specific) <== new | |
| 14:11:34 | efried | sean-k-mooney: os-traits has a precedent for having attributes in __init__.py | |
| 14:12:12 | sean-k-mooney | im looking but or you do hw/cpu/intel.py hw/cpu/amd.py and hw/cpu/x86.py | |
| 14:12:32 | sean-k-mooney | * or you could do hw/cpu/intel.py hw/cpu/amd.py and hw/cpu/x86.py | |
| 14:12:49 | efried | sean-k-mooney: Point is, both intel and amd are x86 | |
| 14:12:53 | sean-k-mooney | yes | |
| 14:12:58 | efried | but have divergent attributes | |
| 14:13:04 | efried | like for this spectre/meltdown stuff | |
| 14:13:13 | sean-k-mooney | well they really should not | |
| 14:13:17 | efried | heh | |
| 14:13:18 | sean-k-mooney | at the traits point of view | |
| 14:13:26 | efried | sean-k-mooney: I mentioned that | |
| 14:13:30 | efried | but kashyap shot me down | |
| 14:13:31 | sean-k-mooney | we shoudl have a common trait where posible | |
| 14:13:42 | efried | yup, read discussion in that patch. | |
| 14:14:14 | sean-k-mooney | kashyap: what was the outcome fo the discussion with openstack security on exposeing thes as traits | |
| 14:14:25 | kashyap | sean-k-mooney: I didn't write to the 'openstack-security' folks. | |
| 14:14:42 | sean-k-mooney | so before we decided on this chagne we shoudl have that disucssion | |
| 14:15:14 | kashyap | sean-k-mooney: Note: at 'traits point of view", it is impossibel to have "divergent attributes". See my last comment | |
| 14:15:21 | kashyap | I carefully discussed it with DanPB yesterday, and posted my discussion | |
| 14:16:28 | sean-k-mooney | sure but just because danpb sates an opion does not mean we will alway follow it but im reading the comments now :) | |
| 14:17:30 | efried | point is, we need HW_CPU_X86_INTEL_FOO and HW_CPU_X86_AMD_BAR as well as HW_CPU_X86_BAZ. I'm just not sure whether that happens with | |
| 14:17:30 | efried | hw/cpu/x86.py: BAZ | |
| 14:17:30 | efried | or | |
| 14:17:30 | efried | hw/cpu/x86/intel.py: FOO | |
| 14:17:30 | efried | hw/cpu/x86/amd.py: BAR | |
| 14:17:31 | efried | hw/cpu/x86/__init__.py: BAZ | |
| 14:17:31 | efried | or we could even leave the existing structure and do | |
| 14:17:32 | efried | hw/cpu/x86.py: INTEL_FOO | |
| 14:17:32 | efried | hw/cpu/x86.py: AMD_BAR | |
| 14:17:33 | efried | hw/cpu/x86.py: BAZ | |
| 14:17:50 | efried | edleafe: Do you have an opinion on this? | |
| 14:18:18 | edleafe | They all come out to the same trait string, right? | |
| 14:18:21 | sean-k-mooney | you can do it with all of the above | |
| 14:18:38 | kashyap | sean-k-mooney: No, you misunderstood me. It's not "because" DanPB said. | |
| 14:18:41 | kashyap | sean-k-mooney: See these two points: | |
| 14:18:48 | aspiers | I'm with sean-k-mooney in that I don't like putting stuff in __init__.py | |
| 14:18:48 | kashyap | * The benefit of HW_CPU_HAS_SPECTRE_CURE is that it glosses over the | |
| 14:18:48 | kashyap | difference between the AMD and Intel flag names for the fix ('IBRS' vs | |
| 14:18:51 | kashyap | 'IBPB'). However, we likely going to want feature- based traits for | |
| 14:18:54 | kashyap | other things: AES, PCID, etc. | |
| 14:18:57 | kashyap | * The HW_CPU_HAS_SPECTRE_CURE is ill-defined :-( since there are many | |
| 14:18:59 | kashyap | Spectre-related bugs. | |
| 14:19:06 | kashyap | sean-k-mooney: Frankly, we're over-thinking on the generic "traits" thing. | |
| 14:19:21 | kashyap | I want to tackle that separately. And first get the granular traits in, without discussing this to the ends of the worlds. | |
| 14:19:25 | sean-k-mooney | kashyap: so traits shoudl not may to qemu feature flags directly | |
| 14:19:44 | mdbooth | stephenfin: I know you called it a nit, but given that I suspect it's a bug it wasn't caught by flake8 I'm going to respin anyway. Thanks for looking! | |
| 14:20:08 | sean-k-mooney | there is no reas an IBRS trait cant map to the IBPB feature on amd and IBRS on intel | |
| 14:20:14 | kashyap | sean-k-mooney: I disagree. | |
| 14:20:29 | stephenfin | mdbooth: Go for it. fwiw, I do have a series to update the hacking version we use but I've WIP'd that til the removal of cells v1 is complete | |
| 14:20:31 | sean-k-mooney | part of os-tratis is to provide a vendor independ set of common traits that can be normalised | |
| 14:20:37 | edleafe | efried: if we're going to be having _INTEL_* and _AMD_* traits, it would make more sense to have them in their own modules | |
| 14:20:38 | stephenfin | There's enough merge conflicts as it is | |
| 14:20:49 | sean-k-mooney | and them mapped to plathform specific thing in the virt dirvers | |
| 14:21:02 | kashyap | efried: Yeah, I'd like to know the answer to your earlier question | |
| 14:21:07 | kashyap | (On the structure) | |
| 14:21:56 | sean-k-mooney | edleafe: we dont really want to add tratis to the __init__.py file in general but we do allow it | |
| 14:22:11 | kashyap | Why we "don't really want"? | |
| 14:22:17 | kashyap | If efried says there's a precedence | |
| 14:22:22 | edleafe | sean-k-mooney: yeah, that's messier, but it does work | |
| 14:22:29 | edleafe | Separate modules is cleaner | |
| 14:22:41 | efried | sean-k-mooney: That's happening all over os-traits. In typical projects I agree it may be best avoided, but when in rome... | |
| 14:22:43 | sean-k-mooney | kashyap: because its condiered an anti pattern in python | |
| 14:22:58 | kashyap | Hm | |
| 14:23:27 | efried | of nine __init__.pyZ in os-traits, five have content. | |
| 14:23:38 | sean-k-mooney | efried: yes i know | |
| 14:23:49 | kashyap | sean-k-mooney: Also, look at: compute/__init__.py | |
| 14:24:14 | sean-k-mooney | although when i suggested adding namespaces in os-traits intially i was hoping to not use __init__.py | |
| 14:24:19 | edleafe | If you're creating a directory hierarchy, and need directory-level traits, the only way to do that is in __init__.py | |
| 14:24:46 | sean-k-mooney | edleafe: yes which is why we use it | |
| 14:25:12 | openstackgerrit | Matthew Booth proposed openstack/nova master: Fix retry of instance_update_and_get_original https://review.opendev.org/658845 | |
| 14:25:26 | efried | edleafe: you can't have x86.py and x86/ ? | |
| 14:25:28 | sean-k-mooney | but do we need hw/cpu/x86/intel.py or just hw/cpu/intel.py | |