Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-19
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
16:24:24 melwitt sean-k-mooney: yeah, that's a way to get visibility by putting them on open discussion agenda
16:24:29 canori01 So while the flavor pinning works, I'm wondering how come it doesn't honor the OS-EXT-AZ:availability_zone of the instance when resizing
16:27:38 sean-k-mooney Cardoe: does the instance have an az set
16:27:48 mriedem canori01: as i said before, if the instance is not created with a specific az, the scheduler does not restrict it to that az
16:28:15 sean-k-mooney Cardoe: sorry that was for canori01
16:28:16 openstackgerrit Stephen Finucane proposed openstack/nova master: Handle unbound vif plug errors on compute restart https://review.openstack.org/626228
16:28:19 mriedem you could set https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_schedule_zone to force a default az, but you might not want that
16:28:22 stephenfin mriedem: Thanks. Addressed
16:29:22 mriedem canori01: alternatively, if each volume is in a specific az, you could set https://docs.openstack.org/nova/latest/configuration/config.html#cinder.cross_az_attach to false and then would need https://review.openstack.org/#/c/469675/ to proxy the volume az to the instance during server create
16:29:39 mriedem cross_az_attach=false means the server and root volume have to be in the same az
16:30:32 mriedem having said that, https://review.openstack.org/#/c/469675/ is kind of fugly and i would like to work on an alternative fix that is less tightly coupled down that stack of code, but haven't found the time
16:30:37 sean-k-mooney mriedem: does that rely on the cinder az mataching the nova az
16:30:43 mriedem sean-k-mooney: yes
16:31:01 mriedem as can be seen here, it's extremely easy to break cross_az_attach=false today https://review.openstack.org/#/c/467674/
16:31:35 mriedem sorrison at nectar is the only deployer i know personally (target uses it also) that uses cross_az_attach and he said their users are just required to always specify an az when creating a server
16:31:50 openstack bug 1694844 in OpenStack Compute (nova) "Boot from volume fails when cross_az_attach=False and volume is provided to nova without an AZ for the instance" [Medium,In progress] https://launchpad.net/bugs/1694844 - Assigned to Matt Riedemann (mriedem)
16:31:50 mriedem b/c of bug 1694844
16:32:15 sean-k-mooney right

Earlier   Later