Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-05-13
21:45:13 openstackgerrit Matt Riedemann proposed openstack/nova master: Handle inactive port binding in _update_port_binding_for_instance https://review.opendev.org/653506
21:52:58 openstackgerrit Matt Riedemann proposed openstack/nova stable/stein: Add functional confirm_migration_error test https://review.opendev.org/658929
21:53:01 mriedem ganso: there is the stein backport ^
21:54:19 ganso mriedem_afk: cool, ok! I will improve the text message of the other ones
22:00:20 aspiers is it just me or is https://etherpad.openstack.org/p/nova-ptg-train borked? is that why there was a https://etherpad.openstack.org/p/nova-ptg-train-2 ? but that seems borked too
22:03:10 openstackgerrit Rodrigo Barbieri proposed openstack/nova stable/rocky: Add functional confirm_migration_error test https://review.opendev.org/658834
22:07:50 sean-k-mooney aspiers: -4 was working last week
22:09:24 sean-k-mooney looks like that is broken too. efried has an offline copy. i have one on my personal laptop too
22:09:30 aspiers sean-k-mooney: yikes, etherpad zombies everywhere
22:09:33 sean-k-mooney we proably should jsut email it to the mailing list
22:09:38 aspiers did it just get too big for etherpad to handle?
22:09:41 efried I made -5 last week
22:09:52 aspiers does the infra team know about this?
22:10:01 sean-k-mooney efried: -5 is not loading either
22:10:01 efried aspiers: I've seen way bigger etherpads that have survived, so I doubt it's the size.
22:10:22 aspiers yeah, -5 not loading for me either
22:10:58 sean-k-mooney there is proably some content in it that it does not like
22:11:01 efried urm, looks like I might have killed my open window to -5
22:11:16 aspiers I've just notified infra
22:11:21 efried was there anything in particular you needed from there?
22:11:21 sean-k-mooney i have a copy i saved offline
22:11:30 sean-k-mooney i can email it to the list
22:12:38 sean-k-mooney if i was to guess at anything i woudl guess it was the non ascii chater that was added to the start of the etherpad
22:23:59 sean-k-mooney aspiers: i sent a mail to the list with subject " [nova][ptg] main etherpad backup"
22:24:54 sean-k-mooney which is apparently held for moderator apporval becasue apprently its over 40KB...
22:25:05 sean-k-mooney this is 2019 right
22:25:37 openstackgerrit Eric Fried proposed openstack/nova master: WIP: TC Vision Reflection https://review.opendev.org/658932
22:30:16 sean-k-mooney efried: am i missing somthing or is the reflect missing form ^
22:30:34 efried sean-k-mooney: You mean did I forget to git-add
22:30:35 efried yes
22:30:37 efried yes I did.
22:30:40 efried thanks
22:30:48 sean-k-mooney ah ok :)
22:30:55 efried doesn't do me much good to "back up my work" and "save my place" if I don't upload the freakin document.
22:31:10 openstackgerrit Eric Fried proposed openstack/nova master: WIP: TC Vision Reflection https://review.opendev.org/658932
22:31:36 efried sean-k-mooney: ^
22:31:37 sean-k-mooney did this come up in the ptg by the way. i was in the fourm session but i never got around to bringin this up in the ptg
22:31:52 efried no, it's just something that's been on my to-do list for months and months
22:32:13 efried okay, since March
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)

Earlier   Later