Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-03
14:32:32 rui-zang If you still have concerns or I do not express it clearly, I am here :)
14:33:26 alex_xu rui-zang: being here whole night :)
14:33:54 rui-zang alex_xu, ->< only have a battery less than 2 hours
14:41:24 maciejjozefczyk jaypipes: ok, found what's wrong with gates :)
14:48:27 HW-Peter hey
14:48:41 HW-Peter Is there any documentation for setting up a Multi Cell CellsV2 Environment
14:49:16 HW-Peter Were running around 500 nodes per location, and are wanting to create a 2nd cell to help with scale
14:50:06 HW-Peter The amount of cells v1/v2 overlap in current documentation makes it difficult to see if the information presented relates to cells v1 or cellsv2
14:50:12 HW-Peter The amount of cells v1/v2 overlap in current documentation makes it difficult to see if the information presented relates to cellsv1 or cellsv2
14:54:33 mriedem HW-Peter: i'm assuming you've seen https://docs.openstack.org/nova/latest/user/cells.html and https://docs.openstack.org/nova/latest/user/cellsv2-layout.html ?
14:54:54 mriedem https://docs.openstack.org/nova/latest/user/cells.html#adding-a-new-cell-to-an-existing-deployment
14:55:56 mriedem HW-Peter: you setup the new db and mq for the new cell and then create the cell mapping pointing at the new db/mq
14:56:17 mriedem new computes in that cell will be configured to point at that cell mq/db
14:56:29 mriedem and then you run discover_hosts to populate the new cell db with the compute_nodes records
14:57:10 mriedem if you're trying to shard an existing db to a new cell, that is a bit harder
14:57:49 mriedem "The amount of cells v1/v2 overlap in current documentation" - if you can point me at what you're referring to i can see if the docs can be made more clear
14:57:59 mriedem i know the ops guide is way out of date
14:58:35 dansmith We probably should be removing cellsv1 words across the board anyway
15:00:48 mriedem i had reorganized the bug user/cells.html doc at one point to move the cells v1 stuff to the bottom so it's not the first thing you see, but abandoned it
15:00:57 mriedem *big
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

Earlier   Later