Earlier  
Posted Nick Remark
#openstack-nova - 2018-12-19
15:41:36 mriedem eric convinced me to do something more targeted
15:41:40 stephenfin mriedem: Any idea why you changed?
15:41:41 stephenfin ah
15:42:13 mriedem https://review.openstack.org/#/c/587498/1/nova/network/os_vif_util.py
15:42:25 mriedem so your fix is just do the same pattern but for vif_type=unbound
15:42:35 openstackgerrit Martin Midolesov proposed openstack/nova master: vmware:add support for the hw_video_ram image property https://review.openstack.org/564193
15:42:49 stephenfin yup
15:43:08 canori01 mriedem: Is it possible to force the resize of an instance to the same host? I have allow_resize_to_same_host, but it seems like it still tries to pick different hosts
15:43:31 mriedem stephenfin: btw it goes back to newton https://review.openstack.org/#/c/350595/
15:44:31 mriedem canori01: i know you can force a cold migrate to a specific host with a newer microversion but i'm not sure if that applies to resize as well
15:44:35 stephenfin backporting fun \o/
15:44:43 mriedem https://developer.openstack.org/api-ref/compute/?expanded=migrate-server-migrate-action-detail#migrate-server-migrate-action
15:44:53 mriedem canori01: ^ host param was added in 2.56
15:45:50 mriedem canori01: ah looks like that won't work for cold migrate at least https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3542
15:46:41 mriedem and you can't specify a host for resize https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L806
15:46:53 mriedem https://developer.openstack.org/api-ref/compute/?expanded=migrate-server-migrate-action-detail,resize-server-resize-action-detail#resize-server-resize-action
15:47:27 mriedem canori01: so the answer is no, and the scheduler is likely picking another host because one is available even though you could use the original host, but maybe weighers or something is picking the other host
15:48:03 openstack Launchpad bug 1790204 in OpenStack Compute (nova) "Allocations are "doubled up" on same host resize even though there is only 1 server on the host" [Medium,Triaged]
15:48:03 mriedem canori01: or the source host is filtered out because of bug https://bugs.launchpad.net/nova/+bug/1790204
15:49:11 openstackgerrit Balazs Gibizer proposed openstack/nova master: Include requested_resources to allocation candidate query https://review.openstack.org/625942
15:49:11 openstackgerrit Balazs Gibizer proposed openstack/nova master: Create RequestGroup from neutron port https://review.openstack.org/625941
15:49:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Extend RequestGroup object for mapping https://review.openstack.org/619527
15:49:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268
15:49:13 openstackgerrit Balazs Gibizer proposed openstack/nova master: Fill the RequestGroup mapping during schedule https://review.openstack.org/619528
15:49:13 openstackgerrit Balazs Gibizer proposed openstack/nova master: Calculate RequestGroup resource provider mapping https://review.openstack.org/616239
15:49:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: Recalculate request group - RP mapping during re-schedule https://review.openstack.org/619529
15:49:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: Pass resource provider mapping to neutronv2 api https://review.openstack.org/616240
15:49:15 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317
15:49:15 openstackgerrit Balazs Gibizer proposed openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459
15:49:16 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reject networks with QoS policy https://review.openstack.org/570079
15:49:16 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reject interface attach with QoS aware port https://review.openstack.org/570078
15:49:17 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor PortResourceRequestBasedSchedulingTestBase https://review.openstack.org/624080
15:49:17 openstackgerrit Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421
15:49:18 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist https://review.openstack.org/625311
15:49:18 openstackgerrit Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310
15:49:19 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543
15:49:31 sean-k-mooney damb that a long patch chain
15:50:28 gibi sean-k-mooney: sorry, it is "just" 17 patches long :)
15:51:08 gibi sean-k-mooney: and I have to do a rebase soon as the second half is in merge conflict :/
15:51:08 sean-k-mooney gibi: no complait form me. its much better then one bing one.
15:51:17 sean-k-mooney im also looking forward to this feature too
15:51:19 gibi sean-k-mooney: yeah, I tried to make small steps
15:51:51 gibi sean-k-mooney: I've just posted a mail to the ML about the status and some summary about the implementation if you like long mails :)
15:51:56 ShilpaSD gibi: Hi
15:52:01 gibi ShilpaSD: hi
15:52:10 mriedem gibi: are you going to kill me? https://review.openstack.org/#/c/625942/2
15:52:51 ShilpaSD gibi: one question, for notification, can we have multi-valued for driver in configuration file?
15:52:58 gibi mriedem: you are right, so I'm not going to kill anybody :)
15:53:32 gibi ShilpaSD: that is coming from oslo, let me dig the doc for it
15:54:33 ShilpaSD gibi: Are you talking about https://docs.openstack.org/oslo.messaging/latest/reference/notifier.html
15:54:45 gibi ShilpaSD: https://docs.openstack.org/oslo.messaging/ocata/opts.html#oslo_messaging_notifications.driver
15:54:49 gibi yes
15:55:06 mriedem funny the config options are not in the oslo.messaging docs
15:55:07 gibi it says multi-valued
15:55:09 mriedem bnemec: ^
15:55:47 mriedem ooo but they're in our docs https://docs.openstack.org/nova/latest/configuration/config.html#oslo-messaging-notifications
15:58:20 gibi mriedem: I think it is in the official too https://docs.openstack.org/oslo.messaging/latest/configuration/opts.html#oslo_messaging_notifications.driver
16:01:47 melwitt mriedem: thanks, taking a look
16:02:18 mriedem gibi: ah yes good call
16:02:23 ShilpaSD gibi: thnaks, actually i want this config option to be set for masakari for notificatins as Default:'', so looking how to be declared this in conf
16:03:40 mriedem [oslo_messaging_notifications]/driver=x
16:04:08 mriedem see http://logs.openstack.org/44/603844/11/check/tempest-full/ee8b609/controller/logs/etc/nova/nova_conf.txt.gz
16:04:40 mriedem if you want multi-valued, you just specify additional driver entries
16:06:25 ShilpaSD mriedem: means as comma seperated?
16:09:13 nicolasbock Hi, good morning. I have a quick (hopefully) question: I am trying to find all key pairs. `openstack keypair list` only shows me keypairs associated with the current user. So I started digging through the Nova DB and stumbled upon a `key_pairs` table, which mysteriously is empty though. Where are those keypairs stored?
16:09:24 nicolasbock Thanks already!
16:13:01 sahid nicolasbock: are you sure to use the right database?
16:13:06 mriedem ShilpaSD: no i think separate lines
16:13:13 mriedem ListOpt is comma-separated
16:13:21 mriedem MultiOpt is multiple entries for the same key
16:13:25 nicolasbock sahid: Yes, that thought occurred to me as well
16:13:26 mriedem they are similar
16:13:28 nicolasbock I'll double check
16:13:34 ShilpaSD mriedem: ok, thnaks
16:13:47 mriedem nicolasbock: key pairs are in the api db
16:14:05 mriedem key pair info per instance is in the instance_extra table in the cell db
16:14:26 nicolasbock Thanks mriedem !
16:14:37 openstack Launchpad bug 1784579 in OpenStack Compute (nova) queens "unable to live migrate instance after update to queens" [Medium,In progress] - Assigned to Matt Riedemann (mriedem)
16:14:37 mriedem stephenfin: sean-k-mooney; btw, i tried to summarize some stuff on that port binding failed bug https://bugs.launchpad.net/nova/+bug/1784579/comments/13
16:15:04 sean-k-mooney mriedem: so i made the continue change and there were not unit test failures with tox -e py27 -- "pci|PCI|hvdevs|update_devices_from_hypervisor_resources" so im going to write a new one
16:15:11 stephenfin mriedem: :D https://bugs.launchpad.net/nova/+bug/1784579/comments/14
16:15:31 sean-k-mooney ill run the full set to be sure but im guessing ther was not test code
16:15:38 stephenfin Probably should have agreed on who was doing that. Oh well
16:16:07 mriedem sean-k-mooney: i'm not at all surprised there was missing test coverage for that code
16:16:37 openstackgerrit Stephen Finucane proposed openstack/nova master: Handle unbound vif plug errors on compute restart https://review.openstack.org/626228
16:16:56 stephenfin mriedem: There's the fix for the latest issue
16:17:05 sean-k-mooney mriedem: look like ther are some test but none that assert that behavior
16:18:01 sahid nicolasbock: i just checked on my devstack i can list the keypairs, i used "nova_api" database
16:20:30 melwitt jackding: review runways are only for approved blueprint implementations, not spec reviews unfortuatnately (please see instructions on the etherpad), so I'm removing the specs from the queue FYI
16:20:52 mriedem stephenfin: comments inline
16:21:18 nicolasbock sahid: Thanks, I found them!
16:21:27 nicolasbock I was looking in the `nova` database before
16:21:41 nicolasbock Thanks for the help sahid and mriedem
16:21:43 sean-k-mooney melwitt: for blueprints/specs we are ment to list them for open discution in the nova team meeting instead right too highlight them
16:22:03 mriedem melwitt: before adding https://blueprints.launchpad.net/nova/+spec/handling-down-cell back into the runway, we should probably know if tssurya is even around
16:22:09 mriedem because i don't think she is and there are -1s on the api change
16:22:14 mriedem so there isn't much point in it being in a runway slot
16:22:19 melwitt mriedem: oh, right
16:24:04 canori01 mriedem: so pinning my flavors to the az's like you suggested yesterday worked fine. So instances don't leave their hypervisor's az if I give them a flavor that associates them to a host aggregate. My situation for the boot volumes is that they are ceph rbd backed. However, each az is backed by a different ceph cluster (because we didn't want a ceph problem in one az to affect the others).
16:24:18 canori01 Probnlem I had is that on resize operations, the scheduler sometimes picked a host in another az and the resize would subsequently fail because that host can't access the rbd volume if it's in a different az

Earlier   Later