| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-13 | |||
| 22:33:22 | sean-k-mooney | ah ok, we discussed this a bit in the fourm session but since bauzas and i were the only novaish people in the room we did not really have a reason other then no one has done it yet for why nova had not done one when asked | |
| 22:33:46 | efried | yeah, I figured it was my responsibility, just hadn't gotten to it yet | |
| 22:33:50 | efried | (dreading, dreading) | |
| 22:36:12 | sean-k-mooney | out of interest is it still technically possible to deploy nova without keystone. | |
| 22:37:10 | sean-k-mooney | i think our configs imply you coudl deploy the api with no auth but im pretty sure it totally would bork things if you tried | |
| 22:37:58 | efried | no idea. I expect I will commit a number of inaccuracies in my writeup due to my relatively brief history on the project. I expect it to be vetted thoroughly by Nova veterans such as yourself before it is considered mergeable. | |
| 22:38:03 | efried | gtg | |
| 22:38:53 | sean-k-mooney | well you can still fall back to noauth2 but i dont know how functional the deployment would be https://github.com/openstack/nova/blob/master/nova/conf/api.py#L24-L36 | |
| 22:38:55 | sean-k-mooney | o/ | |
| 23:30:05 | mriedem_afk | dansmith: well with commenting out that volume attachment stuff i did get a clean run on a volume-backed cross-cell resize confirm tempest test http://logs.openstack.org/56/656656/10/check/nova-multi-cell/f1def72/testr_results.html.gz so i guess i'll just nix that code from the series | |
| 23:30:19 | dansmith | sweet | |
| 23:30:22 | openstackgerrit | John Garbutt proposed openstack/nova master: WIP: Integrating with unified limits https://review.opendev.org/615180 | |
| #openstack-nova - 2019-05-14 | |||
| 01:02:43 | openstackgerrit | Merged openstack/nova master: Add functional confirm_migration_error test https://review.opendev.org/657870 | |
| 07:33:15 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Fix failure to boot instances with qcow2 format images https://review.opendev.org/640271 | |
| 08:39:06 | awalende | Where in the db is stored the volumes that are attached to a specific instance? | |
| 08:39:25 | awalende | I have a failing instance which can't boot because it tries to attach a non existing volume. | |
| 08:46:08 | brinzhang | awalende: You can look down the 'block_device_mapping' table. | |
| 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 | |