Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-03
13:28:44 openstackgerrit Maciej Jozefczyk proposed openstack/nova master: Force refresh instance info_cache during heal https://review.openstack.org/591607
13:28:44 openstackgerrit Maciej Jozefczyk proposed openstack/nova master: Add fill_virtual_interface_list online_data_migration script https://review.openstack.org/614167
13:28:45 openstackgerrit Maciej Jozefczyk proposed openstack/nova master: Rename method _gather_port_ids_and_networks to _get_cached_network_info https://review.openstack.org/628175
13:32:45 jaypipes maciejjozefczyk: reviewing your patches now.
13:44:40 jaypipes maciejjozefczyk: I am sincerely sorry. Please see my comment on the bottom patch :(
13:56:49 openstackgerrit Chris Dent proposed openstack/nova master: Remove placement from nova install docs https://review.openstack.org/628184
13:56:49 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Update nova docs front page for placement removal https://review.openstack.org/628183
13:56:50 openstackgerrit Chris Dent proposed openstack/nova master: Remove placement from contributor doc https://review.openstack.org/628186
13:56:50 openstackgerrit Chris Dent proposed openstack/nova master: Remove link to placement configuration from nova config docs https://review.openstack.org/628185
13:57:09 maciejjozefczyk jaypipes: :) easy
13:57:50 maciejjozefczyk I'm thinking now how previous patch failed on this: http://logs.openstack.org/67/614167/9/check/neutron-grenade/105121b/logs/grenade.sh.txt.gz
13:58:40 maciejjozefczyk jaypipes: maybe its related to the mixed context that you found in online_data_migrations script
14:02:37 alex_xu jaypipes: the PMEM namespace is the way suggested by the qemu, it is best performance way.
14:03:27 alex_xu jaypipes: block mode need a driver layer in the kernel, that isn't real direct access. I asked Rui reply on the spec, I think he can answer this better
14:05:46 alex_xu jaypipes: also in the beginning, we take a look at another way, build a pmem aware filesystem on the pmem namespace, but after talk with virtualization guys, they told me that is a way kernel push forward in the before, but there is bug can't be fixed in the kernel, so pmem namespace is only way for now
14:06:44 alex_xu then the dream of no fragmentation is broken
14:12:05 jaypipes alex_xu: ack
14:27:37 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Exclude build request marker from server listing https://review.openstack.org/626585
14:30:59 rui-zang jaypipes, I just replied in the pmem spec on why "block mode" is not recommended
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?

Earlier   Later