Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-19
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
16:32:41 sean-k-mooney i assume we dont have an api policy/config option to enforce that
16:32:46 canori01 mriedem: is the OS-EXT-AZ:availability_zone attribute on the instance different than what the scheduler looks at? When, instantiate from horizon and choose any availability zone, that gets set with that of the host. So if I were to actually choose an az at that time, then it would honor the az when moving/resizing?
16:33:32 sean-k-mooney i think that is just the az it is currently schdulerd to but i think the schduler looks at the requst spec for the az when picking hosts
16:33:46 melwitt mriedem: I agree with your assessment on that bug you linked. the trace shows "(self.host_state_map[host] for host in seen_nodes)" noting self.host_state_map which is before my fix landed, but also noting that's different than what the code was _before_ my fix landed as well. the previous code was "(self.host_state_map[host] for host in seen_nodes if host in self.host_state_map)" which would also avoid the KeyError, which reminds me,
16:34:09 melwitt of another fix that they also don't have, judging from that trace https://github.com/openstack/nova/commit/d72b33b986525a9b2c7aa08b609ae386de1d0e89

Earlier   Later