Earlier  
Posted Nick Remark
#openstack-nova - 2019-01-03
15:01:11 dansmith ack
15:01:18 dansmith we should just remove it I think
15:01:28 dpawlik mriedem: Hi, I reply you https://review.openstack.org/#/c/628128/ . If you have time please check :)
15:03:03 mriedem dpawlik: replied
15:03:19 mriedem dansmith: yeah, could - if a cells v1 user needs it to upgrade they can get the rocky docs
15:03:42 dpawlik mriedem: how fast. Thanks
15:03:45 dansmith yeah I mean, we're not going to be able to support upgrade forever, so I think just removing the docs about that probably helps to make it clear
15:05:06 mriedem when can we just drop cells v1 again?
15:05:16 mriedem i don't see any specific mention of it in the stein ptg etherpad
15:06:20 mriedem rocky ptg etherpad says we'd drop nova-net before cells v1,
15:06:37 mriedem but stein ptg etherpad says we can't drop nova-net until cells v1 since nova-net only runs if cells v1 is enabled :/
15:06:51 dansmith well, I think we lost steam because (a) removing n-net is hard and (b) cern is still using n-net
15:07:28 dpawlik mriedem: I can listen in my CI job which tox env should be executed, but if I am alone with that problem, we don;'t need to backport the patch.
15:07:33 mriedem surely cern just comments out this line for nova-net: https://github.com/openstack/nova/blob/master/nova/cmd/network.py#L43
15:07:57 dansmith mriedem: that's what they're doing, yes.. I mean if we remove it more than that, it'll be an issue
15:08:12 mriedem yeah i know the service itself
15:08:52 mriedem sorrison is on pike now i think he said
15:08:59 mriedem godaddy is... ?
15:09:02 dansmith they were neutron anyway
15:10:07 mriedem yeah just wondering if/when/why we can't remove cells v1
15:13:28 mriedem anywho, we moved the job to experimental queue, maybe next step is dropping docs, and just continue to whittle away at removing it
15:13:37 mriedem make it less discoverable
15:16:16 openstack Launchpad bug 1804253 in openstack-manuals "Capacity planning and scaling in Operations Guide - cells information is out of date" [Undecided,Confirmed] - Assigned to lei zhang (zhang-lei)
15:16:16 mriedem guess i can take a shot at https://bugs.launchpad.net/openstack-manuals/+bug/1804253
15:29:53 openstackgerrit Maciej Jozefczyk proposed openstack/nova master: Force refresh instance info_cache during heal https://review.openstack.org/591607
15:29:53 openstackgerrit Maciej Jozefczyk proposed openstack/nova master: Add fill_virtual_interface_list online_data_migration script https://review.openstack.org/614167
15:35:59 openstackgerrit Matt Riedemann proposed openstack/nova master: Cleanup soft (anti)affinity weight multiplier options https://review.openstack.org/628205
15:52:20 ade_lee hi -- has anyone seen this error before? http://logs.openstack.org/20/621920/1/gate/barbican-simple-crypto-devstack-tempest/eb68a52/logs/screen-n-cpu.txt.gz#_Jan_02_18_35_13_498931
15:56:49 HW-Peter Thanks for that
15:57:01 HW-Peter Going to start testing this today
15:59:16 ade_lee HW-Peter, sorry - was that directed to me?
15:59:49 openstack Launchpad bug 1808247 in OpenStack Compute (nova) "nova-lvm job failing with ArgsAlreadyParsedError (privsep)" [Medium,Confirmed]
15:59:49 ade_lee mriedem, is the error I posted above related to https://bugs.launchpad.net/nova/+bug/1808247 ?
16:00:31 ade_lee I'm seeing .. "ImportError: cannot import name api"
16:07:51 openstackgerrit Merged openstack/nova-specs master: Add spec for libvirt driver launching AMD SEV-encrypted instances https://review.openstack.org/609779
16:11:20 mriedem ade_lee: yeah since you're using lvm
16:11:21 mriedem Jan 02 18:31:41.561505 ubuntu-xenial-inap-mtl01-0001459779 nova-compute[1225]: DEBUG oslo_service.service [None req-bd4be651-b5b9-4638-86a8-36108a0b464f None None] libvirt.images_type = lvm {{(pid=1225) log_opt_values /usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py:2575}}
16:15:27 ade_lee mriedem, any workaround/fix for that? Its blocking some gate tests
16:15:46 mriedem ade_lee: no idea,
16:15:56 mriedem it looks like something failing in privsep but i'm not expert on that code,
16:16:02 mriedem mikal is probably the best person to ask,
16:16:07 mriedem but he's in australia
16:16:26 mriedem i also don't know why it's only hitting the lvm configuration
16:17:36 mriedem should maybe try running with this set to DEBUG https://github.com/openstack/nova/blob/master/nova/config.py#L46
16:17:41 mriedem and see if that helps show where privsep is blowing up
16:18:18 ShilpaSD hi All, doing restacking, but failing with error "neutronclient.Unauthorized", any suggestions?
16:18:46 ade_lee mriedem, ok -- will try doing that
16:18:50 ade_lee thanks
16:24:00 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: debugging lvm privsep failures https://review.openstack.org/628213
16:24:01 mriedem ade_lee: ^
16:24:46 ade_lee mriedem, cool - I'll piggyback off that
16:57:26 openstackgerrit Chris Dent proposed openstack/nova master: Remove placement from nova install docs https://review.openstack.org/628184
16:57:26 openstackgerrit Chris Dent proposed openstack/nova master: Update nova docs front page for placement removal https://review.openstack.org/628183
16:57:27 openstackgerrit Chris Dent proposed openstack/nova master: Remove link to placement configuration from nova config docs https://review.openstack.org/628185
16:57:28 openstackgerrit Chris Dent proposed openstack/nova master: Remove placement from contributor doc https://review.openstack.org/628186
17:01:56 openstackgerrit Matt Riedemann proposed openstack/nova master: Add microversion 2.68 to support for volume-backed server rebuild https://review.openstack.org/627518
17:09:27 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: add spec "show-server-numa-topology" https://review.openstack.org/612256
17:51:21 dansmith mriedem: while we're waiting for confirm, we still have the original instance root disk still on the source, right?
17:52:13 mriedem per v2 of the spec i said we destroy the guest
17:52:23 mriedem on revert we re-spawn it
17:52:53 dansmith destroy, but does that mean delete too?
17:52:56 mriedem i went the driver.destroy route because that unplugs vifs and disconnects volumes on the source host
17:53:02 dansmith right, saw that
17:53:18 dansmith was not sure that would delete the image though as I thought there's a flag for that and was thinking maybe you were planning to not
17:54:16 mriedem that driver.destroy method has a destroy_disks flag which defaults to True,
17:54:59 mriedem which deletes the instance path,
17:55:04 dansmith okay let me finish my comment on v2 and you can see what I'm asking
17:55:04 mriedem which is where the root disk image is right?
17:55:22 dansmith yes
17:55:46 dansmith mriedem: look at my last two comments just now
17:56:17 mriedem i think the main difference between destroy and migrate_disk_and_power_off is that migrate_disk_and_power_off powers off the instance rather than destroy it (and copies the disks obviously), it also disconnects volumes like destroy, but doesn't unplug vifs for some weird reason
18:04:06 dansmith mriedem: added a few more comments, but I think if you fix the image question I'll be ready to +2
18:04:30 mriedem replying to the first set
18:06:48 openstackgerrit Ifat Afek proposed openstack/nova master: The field instance_name was added to InstanceCreatePayload https://review.openstack.org/627967
18:09:08 openstackgerrit Adrian Chiris proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365
18:09:08 openstackgerrit Adrian Chiris proposed openstack/nova master: Add free for claimed, allocated devices https://review.openstack.org/616120
18:09:09 openstackgerrit Adrian Chiris proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115
18:09:09 openstackgerrit Adrian Chiris proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929
18:17:48 ade_lee mriedem, hey is the log with the privsep logging on (I think) -- http://logs.openstack.org/20/621920/2/check/barbican-simple-crypto-devstack-tempest/f013bd9/logs/screen-n-cpu.txt.gz
18:18:11 ade_lee mriedem, I do see this -- http://logs.openstack.org/20/621920/2/check/barbican-simple-crypto-devstack-tempest/f013bd9/logs/screen-n-cpu.txt.gz#_Jan_03_17_17_25_532237
18:18:45 ade_lee mriedem, and also this -- http://logs.openstack.org/20/621920/2/check/barbican-simple-crypto-devstack-tempest/f013bd9/logs/screen-n-cpu.txt.gz#_Jan_03_17_17_27_635858
18:21:07 openstackgerrit Adam Spiers proposed openstack/nova-specs master: AMD SEV: address final feedback received prior to merge https://review.openstack.org/628252
18:22:59 openstackgerrit Adam Spiers proposed openstack/nova-specs master: AMD SEV: address final feedback received prior to merge https://review.openstack.org/628252
18:37:53 mriedem ade_lee: yeah this http://logs.openstack.org/20/621920/2/check/barbican-simple-crypto-devstack-tempest/f013bd9/logs/screen-n-cpu.txt.gz#_Jan_03_17_17_25_525734
18:38:16 mriedem looks like we have a classic circular import
18:40:20 mriedem ade_lee: yeah it's this change https://github.com/openstack/nova/commit/26521718bdba3bccbf6270e26b76754c26304658#diff-31323cc5d9a493e21871761c5051db7c
18:40:25 mriedem merged on dec 8 which is when the failures started
18:42:32 mriedem i need to wrap up replying to comments on a spec and then i can push a change to see if i can fix that
18:42:55 dansmith why is tripleo the only thing hitting that I wonder?
18:44:10 mriedem that lvm thing? it's not
18:44:14 mriedem the nova-lvm job is busted by it
18:50:40 dansmith oh okay
18:51:23 dansmith first saw it come up in #tripleo so I just assumed
19:03:46 mriedem dansmith: replies inline https://review.openstack.org/#/c/616037/ thanks - seems like non-drastic changes
19:04:26 mriedem maybe i'll change that 'open questions' section to 'known issues' to denote things we know about but don't really care about right now and could be dealt with later if necesary
19:08:18 mriedem jaypipes: so in yonglihe's show server topology spec, your alternative is the GET /servers/{server_id}/topology which would just be NUMA info (not pci devices) and admin-only by default?
19:08:57 jaypipes mriedem: right
19:09:18 jaypipes mriedem: with work on a /devices endpoint done in a separate spec (with efried's help)
19:10:02 mriedem i believe i said in the ML thread that i was ok with /diagnostics or a sub-resource, as long as it wasn't something shoe-horned into the normal response body (GET /servers/{server_id}) or list (GET /servers or GET /servers/detail)
19:10:13 mriedem so whatever

Earlier   Later