Earlier  
Posted Nick Remark
#openstack-nova - 2018-12-19
15:35:52 stephenfin mriedem++
15:35:54 mriedem this https://review.openstack.org/#/c/603844/ would also be related
15:36:04 mriedem as a forced recovery action
15:37:26 mriedem sean correctly pointed out i should have used related/partial bug https://review.openstack.org/#/c/587498/3//COMMIT_MSG@35
15:37:30 mriedem i must have missed that
15:37:50 sean-k-mooney https://bugzilla.redhat.com/show_bug.cgi?id=1645316 needs https://review.openstack.org/#/c/591607/
15:37:51 openstack bugzilla.redhat.com bug 1645316 in openstack-nova "Nova fails to attach both interfaces to VM after hypervisor reboot" [High,On_dev] - Assigned to smooney
15:38:04 mriedem stephenfin: i think the heal conversation is here https://review.openstack.org/#/c/587498/1/nova/compute/manager.py@956
15:38:24 mriedem i have to come back on https://review.openstack.org/#/c/591607/
15:38:28 mriedem too much gd stuff going on
15:38:42 mriedem sean-k-mooney: are you working on that pci device bogus removal patch?
15:38:44 mriedem or should i?
15:39:10 stephenfin mriedem: Yeah, sorry. Let me draft a bug report and a patch and we can discuss later. As you were
15:39:21 sean-k-mooney am i just booted up my sriov env so ill make the change now and see if that works
15:39:45 mriedem stephenfin: bug report for the unbound thing? yeah i guess just refer to these other 20 bugs for binding_failed and it's the same issue
15:40:20 stephenfin Yeah, maybe I should just make the existing bug more generic and re-open it
15:40:44 mriedem stephenfin: btw, PS1 of my patch would have handled unbound https://review.openstack.org/#/c/587498/1/nova/network/os_vif_util.py
15:40:57 mriedem since it raised a new UnsupportedVifTypeConversion exception for anything we can't convert
15:41:09 mriedem and handled in init_host https://review.openstack.org/#/c/587498/1/nova/compute/manager.py
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 mriedem canori01: or the source host is filtered out because of bug https://bugs.launchpad.net/nova/+bug/1790204
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:49:11 openstackgerrit Balazs Gibizer proposed openstack/nova master: Create RequestGroup from neutron port https://review.openstack.org/625941
15:49:11 openstackgerrit Balazs Gibizer proposed openstack/nova master: Include requested_resources to allocation candidate query https://review.openstack.org/625942
15:49:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268
15:49:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Extend RequestGroup object for mapping https://review.openstack.org/619527
15:49:13 openstackgerrit Balazs Gibizer proposed openstack/nova master: Calculate RequestGroup resource provider mapping https://review.openstack.org/616239
15:49:13 openstackgerrit Balazs Gibizer proposed openstack/nova master: Fill the RequestGroup mapping during schedule https://review.openstack.org/619528
15:49:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: Pass resource provider mapping to neutronv2 api https://review.openstack.org/616240
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:15 openstackgerrit Balazs Gibizer proposed openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459
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:16 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reject interface attach with QoS aware port https://review.openstack.org/570078
15:49:16 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reject networks with QoS policy https://review.openstack.org/570079
15:49:17 openstackgerrit Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421
15:49:17 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor PortResourceRequestBasedSchedulingTestBase https://review.openstack.org/624080
15:49:18 openstackgerrit Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310
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: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 sean-k-mooney gibi: no complait form me. its much better then one bing one.
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: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 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: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: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

Earlier   Later