Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-20
16:33:03 sean-k-mooney im kind of nutral on this i prefer patch but i can live with either
16:33:21 dansmith I'm not generally a fan of PATCH
16:33:36 gibi honestly I can live with both PUT and PATCH now.
16:33:45 gibi damn, this is hard.
16:33:50 gibi soo many decisions
16:33:54 gibi :)
16:35:17 gmann i am ok with any new API (PATCH or Action) other than changing existing PUT.
16:35:32 gmann action can be one option then.
16:43:20 sean-k-mooney action would have made sense for swap volume
16:43:35 sean-k-mooney im not sure it makes sense here but it would be an option i guess
16:45:00 melwitt I think the ideal would be move swap volume to an action and let PUT be for changing stuff like delete_on_termination, right? but that turns it into boiling the ocean when the author is just trying to add something simple
16:45:22 sean-k-mooney ya
16:47:05 melwitt on the admin-only aspect, I think any "other" params that might end up being allowed in the PUT API need to be able to be controlled by a new separate policy rule right. so that an operator could leave swap volume admin-only but delete_on_termination could be non-admin
16:47:27 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Report storage bus traits https://review.opendev.org/666914
16:47:28 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Use domain capabilities to get supported device models https://review.opendev.org/666915
16:47:28 openstackgerrit Stephen Finucane proposed openstack/nova master: Add transform_image_metadata request filter https://review.opendev.org/665775
16:47:28 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Update '_get_foo_traits' docstrings https://review.opendev.org/708912
17:06:02 openstackgerrit Merged openstack/nova master: Clean up allocation if unshelve fails due to neutron https://review.opendev.org/706868
17:25:54 sean-k-mooney alex_xu: do you have any documentation on how to configre a host use pmem with openstack.
17:26:58 sean-k-mooney alex_xu: we would like to test it in the next few weeks to plan for how to support it downstream in the osp product but it appears that the defivcie do not have regions avaiable
17:27:15 sean-k-mooney so we are stuck at the create namespace step
17:28:20 sean-k-mooney alex_xu: if you can point use in the right direction for how to create a regaion i think we should be able to create namespaces and configure nova form that point
17:29:42 sean-k-mooney do we have to cofigure kernel memmap options? memmap=12G!4G
17:30:14 sean-k-mooney or is that just for emulated nvdimms
17:32:02 sean-k-mooney i thnk it is jsut for emulated devices and based on https://docs.pmem.io/persistent-memory/getting-started-guide/creating-development-environments/linux-environments it does not support DevDax mode so that is not what we are looking for i guess
17:34:16 sean-k-mooney ah i might have found what i was looking for https://docs.pmem.io/ndctl-user-guide/managing-regions#enabling-regions
17:46:34 sean-k-mooney alex_xu: actully no that is not what i watn but looking at https://software.intel.com/en-us/articles/quick-start-guide-configure-intel-optane-dc-persistent-memory-on-linux i need to use ipmctl to create the regions on teh device then ndctl can be used to manage the namespaces after that point
17:54:53 sean-k-mooney ok i think i understand how to configre this but i might ping you about it at some other point if we get stuck
18:05:50 openstackgerrit Lee Yarwood proposed openstack/nova master: docs: Add stable device rescue docs https://review.opendev.org/700837
18:36:27 openstackgerrit Ivaylo Mitev proposed openstack/nova master: Faults from cell DB missing in GET /servers/detail https://review.opendev.org/699176
19:15:21 lucidguy We still can't get instances to launch with over 1TB of mem. Soooo frustrating.
19:15:49 lucidguy Anyone have experience with this?
19:17:16 artom melwitt, you might be able to clarify this - but in the Ironic case (that's the only virt drive that I can think of where this would apply), the compute host is where the nova-compute and ironic virt driver run, and the compute *node* is the actual baremetal machine that serves as hypervisor, right?
19:17:34 artom So a single compute *host* manages multiple compute *nodes*?
19:17:45 melwitt artom: that's correct
19:18:20 melwitt the values in the compute_nodes table are "host" and "hypervisor_hostname" where the latter is the ironic node
19:19:45 artom melwitt, ok, so my thinking was correct, thanks!
19:33:57 lucidguy Can someone tell me why this vm crashes/kernel panics on startup.
19:34:05 lucidguy https://paste.ubuntu.com/p/KPC9qXVgPK/
23:59:08 openstackgerrit Merged openstack/nova master: trivial: Update '_get_foo_traits' docstrings https://review.opendev.org/708912
#openstack-nova - 2020-02-21
00:26:43 brinzhang sean-k-mooney: are you around?
02:18:33 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Support re-configure deleted_on_termination in server https://review.opendev.org/580336
02:19:34 brinzhang alex_xu, gibi: I was update the spec for PTACH API, please review
02:57:12 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Support re-configure deleted_on_termination in server https://review.opendev.org/580336
02:58:56 brinzhang alex_xu: thanks, updated
09:57:34 openstackgerrit Stephen Finucane proposed openstack/python-novaclient master: setup.cfg: Various Python 3 fixes https://review.opendev.org/708824
09:57:35 openstackgerrit Stephen Finucane proposed openstack/python-novaclient master: tox: Configure 'ignore_basepython_conflict' https://review.opendev.org/708830
09:57:35 openstackgerrit Stephen Finucane proposed openstack/python-novaclient master: Remove six https://review.opendev.org/708831
09:57:36 openstackgerrit Stephen Finucane proposed openstack/python-novaclient master: Bump to hacking 2.x https://review.opendev.org/708832
09:57:36 openstackgerrit Stephen Finucane proposed openstack/python-novaclient master: trivial: Remove 'u' prefix from string https://review.opendev.org/709080
09:57:37 openstackgerrit Stephen Finucane proposed openstack/python-novaclient master: Random cleanups https://review.opendev.org/709081
10:45:50 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Remove native LUKS compat code https://review.opendev.org/669121
11:30:12 happyhemant Hi folks, I am creating instance in openstack with SRIOV, hugepages and cpu pinning. Creation of instance works with only SRIOV. Similarly with cpu-pinning and hugepage and without SRIOV works as well. But creating instance together with SRIOV, cpu-pinning and hugepages does not work. I found some logs in nova conductor and scheduler have a look to those if anybody can help would be really appreciated
11:30:45 happyhemant nova-scheduler logs https://www.irccloud.com/pastebin/KqD8zxqU/nova-scheduler%20
11:31:42 happyhemant nova-conductor logs https://www.irccloud.com/pastebin/e580zd4R/nova-conductor
12:12:42 Tony31 hi nova team. When scheduling an instance via Horizon I can select `availability zone`. Is this availability zone information passed to Cinder? I would like to select a specific cinder backend with nova availability zone. I have tried setting the cinder `backend_availability_zone` to match the nova AZ but I am unable to get a match. I have enabled
12:12:43 Tony31 in Cinder `scheduler_default_filters = AvailabilityZoneFilter` which i had found in the docs is already enabled by default. Could anyone help nudge me in the right direction?
13:47:10 redrobot Hello, Nova friends! I would appreciate reviews on this updated bugfix patch: https://review.opendev.org/#/c/679502/
14:07:02 openstackgerrit Ivaylo Mitev proposed openstack/nova master: Faults from cell DB missing in GET /servers/detail https://review.opendev.org/699176
15:29:03 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support unshelve with qos ports https://review.opendev.org/704759
15:29:04 openstackgerrit Balazs Gibizer proposed openstack/nova master: Enable unshelve with qos ports https://review.opendev.org/705475
15:31:01 efried gibi, alex_xu, brinzhang: Where are we on the delete-on-termination spec? Do we need to defer?
15:31:04 gibi stephenfin: I had to resolve a merge conflict so I lost your +2 on https://review.opendev.org/#/c/704759/ Could you plug it back?
15:31:47 gibi efried: as far as I understand gmann is OK to have PATCH or a POST with a different action and alex_xu does not like the idea of PATCH
15:31:52 openstackgerrit Balazs Gibizer proposed openstack/nova master: Merge qos related renos for Ussuri https://review.opendev.org/706766
15:32:11 gibi efried: I don't see that alex_xu and gmann agreed on a compromise
15:32:13 brinzhang I want to look gibi and alex_xu, if they are agree with this patch, I will be ok whether defer or pass
15:33:18 brinzhang gibi: I was disscussed with alex_xu on wechat, he is ok for PTACH
15:33:50 gibi brinzhang: OK. Then we have an agreement. Let me quickly re-read the spec but then I'm +2 on it
15:34:08 brinzhang gibi: thanks
15:35:20 gibi done. I'm +2
15:36:20 brinzhang gibi: cool, alex_xu maybe busy from afternoon, gmann are you around?
15:37:30 brinzhang efried: Is this need another +2 for it, that you can +1W ?
15:39:14 efried brinzhang: We definitely need two +2s. And since alex_xu was one of the crucial voices in the process, I think one of them should be his.
15:40:48 efried brinzhang: I would value gmann's +1 for sure, but we need alex_xu to make it go.
15:41:23 brinzhang efried: sure, hope alex_xu is not sleeping :)
15:41:41 brinzhang efried: I will ping him now
15:47:20 brinzhang efried: I think alex_xu is sleeping, I know our team are considering to cut spec in U release because of mriedem and you away, if so, I agree defer this. I am glad to meet this feature has a solution that everyone can agree on.
15:48:07 efried brinzhang: Okay. I'll give it to the end of my day and defer if we haven't heard back from alex_xu. Thanks for understanding.
15:48:23 brinzhang gibi, alex_xu, gmann, sean-k-mooney: thanks, and if gmann would like to +1, I will be happy :)
15:48:50 gibi efried: agree
15:49:03 brinzhang efried, gibi: thanks
15:49:08 gibi brinzhang: thanks
16:02:55 openstackgerrit Balazs Gibizer proposed openstack/nova stable/train: Reproduce bug 1862633 https://review.opendev.org/709166
16:02:55 openstack bug 1862633 in OpenStack Compute (nova) "unshelve leak allocation if update port fails" [Medium,Fix released] https://launchpad.net/bugs/1862633 - Assigned to Balazs Gibizer (balazs-gibizer)
16:02:55 openstackgerrit Balazs Gibizer proposed openstack/nova stable/train: Clean up allocation if unshelve fails due to neutron https://review.opendev.org/709167
16:16:27 stephenfin gibi: done
16:16:34 gibi stephenfin: thank you
16:28:10 sean-k-mooney gibi: there are potentially other issues with unshelve. we have an open dowsntream bug report that sugges we do not correclty handel neutron sriov deivce on unshelve
16:28:42 gibi sean-k-mooney: could be. this bug was come up when I added qos support for unshelve
16:28:42 sean-k-mooney gibi: basicaly i thinke we do the claim and port update after we regenerate the xml on queens
16:29:14 sean-k-mooney so i think we have an odering issue in that code in generall but not sure if its still a thing on master
16:31:57 gibi sean-k-mooney: there is a FIXME in the code https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L6497
16:32:04 gibi but that is about error handling + cleanup
16:32:22 gibi the port update happens before we call driver.spawn
16:32:36 gibi https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L6474-L6480
16:33:47 gibi the problem might be that we update the port before the instance_claim
16:35:56 gibi but I lack the brain power on this Friday evening to dig this further
17:07:33 openstackgerrit Mark Goddard proposed openstack/nova master: Add functional regression test for bug 1853009 https://review.opendev.org/695012
17:07:33 openstack bug 1853009 in OpenStack Compute (nova) "Ironic node rebalance race can lead to missing compute nodes in DB" [Undecided,In progress] https://launchpad.net/bugs/1853009 - Assigned to Mark Goddard (mgoddard)

Earlier   Later