| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-14 | |||
| 08:48:55 | brinzhang | awalende: There may be information about the disk you need with the instance. | |
| 08:51:49 | awalende | Thanks! I found the entry | |
| 08:52:16 | awalende | now to find out which field to manipulate in order to detach it | |
| 08:52:45 | awalende | or is it safe to delete the rows with the non existing volume? | |
| 09:20:32 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Add host and hypervisor_hostname flag to create server https://review.opendev.org/645520 | |
| 09:37:30 | openstackgerrit | Surya Seetharaman proposed openstack/python-novaclient master: [Docs] Update client docs to add reason and locked options https://review.opendev.org/659000 | |
| 10:50:56 | openstackgerrit | Hamdy Khader proposed openstack/nova master: [WIP] OVS DPDK port representors support https://review.opendev.org/658785 | |
| 12:05:26 | openstackgerrit | Hamdy Khader proposed openstack/os-vif master: [WIP] OVS DPDK port representors support https://review.opendev.org/658786 | |
| 12:29:36 | openstackgerrit | Alexandre arents proposed openstack/nova master: Fix live-migration when glance image deleted https://review.opendev.org/659054 | |
| 12:45:27 | kashyap | alex_xu: Hi, I have abandoned this spec (the `cpu_model_list` thing) after further discussions w/ the QEMU & libvirt folks: https://review.opendev.org/#/c/642030/ | |
| 12:57:44 | alex_xu | kashyap: ok, got it | |
| 13:45:27 | mdbooth | bauzas: I also thought we might have other bugs like https://review.opendev.org/#/c/658845/, so I posted to the ML earlier | |
| 13:45:58 | bauzas | mdbooth: yup that's why I left a comment | |
| 13:46:04 | mdbooth | bauzas: ack | |
| 13:46:14 | bauzas | we have this bug, so we can fix it, but maybe we should also look at other methods | |
| 13:46:21 | mdbooth | bauzas: Indeed | |
| 13:47:17 | mdbooth | bauzas: And be generally stricter about not modifying argument data. It causes a bunch of issues, but I think this is the subtlist I've encountered. | |
| 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) | |