| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-17 | |||
| 06:52:27 | openstackgerrit | Takashi NATSUME proposed openstack/nova stable/queens: Add description of custom resource classes https://review.openstack.org/619125 | |
| 06:52:43 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in virt/test_block_device.py https://review.openstack.org/566153 | |
| 06:53:15 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Use oslo_db.sqlalchemy.test_fixtures https://review.openstack.org/609352 | |
| 06:53:36 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix best_match() deprecation warning https://review.openstack.org/611204 | |
| 06:53:48 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3) https://review.openstack.org/574104 | |
| 08:19:34 | izza_ | hi guys,,, | |
| 08:19:49 | izza_ | can you please help us on openstack helm rocky | |
| 08:26:16 | izza_ | encounetered issue : {2} tempest.api.identity.admin.v3.test_list_users.UsersV3TestJSON.test_list_users [0.110978s] ... FAILED | |
| 08:26:21 | izza_ | in single node openstack helm | |
| 09:46:58 | gmann | izza_: you can ping this on openstack-qa channel. i can help you on failure | |
| 11:07:03 | openstackgerrit | Merged openstack/nova master: Replace ThreadPoolExecutor with GreenThreadPoolExecutor https://review.openstack.org/624740 | |
| 13:16:38 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Reject migration requests when source is down https://review.openstack.org/623489 | |
| 13:27:59 | openstackgerrit | Chris Dent proposed openstack/nova master: Correct lower-constraints.txt and the related tox job https://review.openstack.org/622972 | |
| 13:38:41 | lyarwood | coreycb: https://review.openstack.org/#/c/579004/ - are you working on this btw? I have some time today to address the comments otherwise. | |
| 13:40:45 | coreycb | lyarwood: I'm not actively working on it. seyeongkim had taken it over for me. he appears to not be in here. | |
| 13:41:49 | lyarwood | coreycb: ack np, I'll respin now in that case. | |
| 13:42:14 | coreycb | lyarwood: i asked him to join. i think we'd both not be opposed to your help :) | |
| 13:42:24 | coreycb | lyarwood: thanks | |
| 13:45:46 | stephenfin | melwitt: Think this is something you could look at, when you're about? https://review.openstack.org/#/c/611088/ | |
| 13:54:53 | cdent | scheduler/placement meeting in #openstack-meeting-alt in 5 minutes if people want one | |
| 14:02:50 | mgariepy | anyone is aware of an issue with pci passthrough i created the vms with pike and upgraded the cluster to queens, when i restart the vms i loose all the pci devices. the instances boot without them. | |
| 14:03:59 | spatel | sean-k-mooney: morning | |
| 14:04:27 | openstack | Launchpad bug 1808738 in OpenStack Compute (nova) "No net device was found for VF" [Undecided,New] | |
| 14:04:27 | spatel | sean-k-mooney: any input here? https://bugs.launchpad.net/nova/+bug/1808738 | |
| 14:09:13 | sean-k-mooney | right so basically i think that happens if your VF is bound to vfio-pci | |
| 14:09:46 | sean-k-mooney | spatel: ^ | |
| 14:10:01 | spatel | hmm! how do i check that? | |
| 14:10:10 | sean-k-mooney | as a result there is not netdev created for the VF and you get that warning | |
| 14:10:10 | spatel | sean-k-mooney: ^ | |
| 14:10:53 | sean-k-mooney | you coudl check in sysfs what driver one of the vfs e.g. 03:09.4 is boudn too | |
| 14:11:10 | spatel | let me check | |
| 14:12:25 | spatel | /sys/bus/pci/devices/0000\:03\:09.4/ which dir i should check here for that? | |
| 14:13:14 | spatel | I think this one? cat /sys/bus/pci/devices/0000\:03\:09.4/driver/bind | |
| 14:13:26 | sean-k-mooney | ls -al /sys/devices/pci0000\:00/0000\:03\:09.4/ | |
| 14:13:58 | sean-k-mooney | the driver director should be a symlink | |
| 14:14:07 | sean-k-mooney | it will look something like this driver -> ../../../bus/pci/drivers/e1000e | |
| 14:14:31 | spatel | oh! yes its /sys/bus/pci/devices/0000:03:09.4/driver -> ../../../../bus/pci/drivers/vfio-pci | |
| 14:15:06 | sean-k-mooney | if you checked ls -al /sys/devices/pci0000\:00/0000\:03\:09.4/net it either would not exist or be empty is my guess | |
| 14:15:16 | sean-k-mooney | so ya the warning is expected | |
| 14:16:51 | spatel | yes /sys/bus/pci/devices/0000:03:09.4/net: No such file or directory | |
| 14:17:34 | sean-k-mooney | right so the PF has virtual functions that are bount to vfio-pci which does not create netdevs for the VFs | |
| 14:18:07 | spatel | hmm! | |
| 14:18:28 | spatel | so no way we reduce that logging except filter in syslog right? | |
| 14:18:38 | spatel | its just filling my disk with that warning :) | |
| 14:18:46 | sean-k-mooney | you can filter in nova | |
| 14:18:56 | spatel | how? | |
| 14:19:16 | sean-k-mooney | ill get the config option one sec | |
| 14:20:06 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_log_levels | |
| 14:20:12 | spatel | reading... | |
| 14:21:02 | sean-k-mooney | you should be able to add nova.pci.utils=ERROR | |
| 14:21:27 | spatel | wow! that would be amazing :) | |
| 14:21:37 | spatel | i didn't know you can filter log by nova applicatoon | |
| 14:21:44 | spatel | application* | |
| 14:21:44 | sean-k-mooney | not you will have to set all the default too | |
| 14:21:49 | sean-k-mooney | *note | |
| 14:22:21 | sean-k-mooney | we use pythongs loggin framework so you can filter logs by module | |
| 14:22:34 | spatel | so i have to set all default list in nova.conf including nova.pci.utils=ERROR right? | |
| 14:23:21 | sean-k-mooney | i think so that said i have never tried to limit logs from nova its self but i think that will work | |
| 14:23:36 | spatel | i will give it a try on lab :) | |
| 14:23:44 | spatel | thanks for the tip :) | |
| 14:24:11 | openstack | Launchpad bug 1807251 in OpenStack Dashboard (Horizon) "Horizon Overview summary showing wrong numbers " [Undecided,Incomplete] | |
| 14:24:11 | spatel | sean-k-mooney: check this out https://bugs.launchpad.net/horizon/+bug/1807251 | |
| 14:26:44 | openstack | Launchpad bug 1808738 in OpenStack Compute (nova) "No net device was found for VF" [Undecided,New] | |
| 14:26:44 | spatel | sean-k-mooney: you can close this issue with your comments https://bugs.launchpad.net/nova/+bug/1808738 | |
| 14:27:29 | openstackgerrit | Jack Ding proposed openstack/nova master: Improve libvirt image and snapshot handling https://review.openstack.org/616692 | |
| 14:28:07 | sean-k-mooney | im triaging it currently as low as the wraning is noisy as you said and does not explain why it happens. | |
| 14:28:26 | sean-k-mooney | but it can fill your disk which is annoying. | |
| 14:29:17 | spatel | sean-k-mooney: it would be good if adjust code to understand behavior and don't sent WARNING | |
| 14:29:24 | openstackgerrit | Jack Ding proposed openstack/nova master: Correct instance port binding for rebuilds/reboots https://review.openstack.org/603844 | |
| 14:31:27 | sean-k-mooney | spatel: i was thinking of bumping it down to debug | |
| 14:31:54 | sean-k-mooney | spatel: ther freatre that need the netdev to exist but none that are critical | |
| 14:32:25 | sean-k-mooney | the main one being nic feature based schduling which is only half implemnted | |
| 14:32:46 | sean-k-mooney | so its not very usfull currently since it does not work | |
| 14:33:59 | sean-k-mooney | you may also be unable to use vnic_type=macvtap | |
| 14:37:11 | mriedem | gibi: we have a runways queue spot open https://etherpad.openstack.org/p/nova-runways-stein but i'm not sure if we should put your 2nd mention of https://blueprints.launchpad.net/nova/+spec/bandwidth-resource-provider in there or just assume it will be covered by the existing entry? | |
| 14:37:23 | mriedem | they are all in a series so i'm not sure why you had that in the etherpad twice | |
| 14:49:17 | lyarwood | mriedem: https://review.openstack.org/#/c/579004/6/nova/virt/block_device.py - I'm trying to follow up on your comments here, quick question if you have a second. In the case where the BDM doesn't have an attachment_id can we just create one or do we still need to use the v2 APIs? | |
| 14:50:23 | lyarwood | cinderv2 is deprecated but I'm not sure if the intention here was to always assume that we had access to cinderv3 when updating the connection_info here or not. | |
| 14:50:47 | mriedem | cinder v3.0 is backward compatible with v2 apis | |
| 14:51:07 | mriedem | so if we have a legacy attachment (no attachment_id in the bdm) we can use the old initialize_connection flow | |
| 14:52:08 | mriedem | converting legacy attachments to "new style" attachments in refresh_connection_info is an interesting thought, | |
| 14:52:18 | mriedem | but since this is something that needs to be backported, i would avoid that in this change | |
| 14:53:09 | mriedem | we definitely do need to get code in to start migrating the old style attachments ( https://review.openstack.org/#/c/541420/ https://review.openstack.org/#/c/549130/ ) | |
| 14:53:17 | mriedem | otherwise we'll never be able to drop those old flows | |
| 14:54:38 | lyarwood | ack yeah thanks just had to remind myself about the v2/v3 compat, that somehow slipped my mind. | |
| 14:54:53 | lyarwood | and yeah this is getting backported if it ever lands | |
| 14:55:01 | lyarwood | so converting isn't helpful here yet | |
| 14:55:15 | lyarwood | maybe in a follow up, unless you're already doing that in the above changes | |
| 15:01:42 | mriedem | i'm not | |
| 15:02:10 | mriedem | we really have two things that need to be done: 1. bfv where nova-compute creates new volumes needs to use the new flow, that's the first patch above, | |
| 15:02:23 | mriedem | 2. migrate existing attachments, which can only be done on the compute b/c we need the host connector | |
| 15:02:28 | mriedem | that's the 2nd patch | |
| 15:02:54 | mriedem | it does that on n-cpu startup in a separate thread on each compute using a specialized db query to try and make this as targeted as possible, because i think that's what we talked about doing in dublin, | |
| 15:03:37 | mriedem | but in berlin there were suggestions of just migrating on first access of a legacy attachment, like maybe during move operations or reboot (like refresh_connection_info), | |
| 15:03:44 | mriedem | so idk where we are on migrating existing attachments | |
| 15:03:53 | gibi | mriedem: regarding runways. You are correct, everything related to bandwidth is in a single chain of commits. I just finished the second set of commits _after_ the first set was already in the queue | |
| 15:04:06 | mriedem | we need to have some kind of data migration though otherwise we can't ever drop the old code paths | |
| 15:04:09 | gibi | mriedem: and I did not want to change an item in the queue | |
| 15:04:25 | spatel | sean-k-mooney: sorry i was in meeting my IRC client kick me out | |
| 15:04:41 | mriedem | gibi: ok. fwiw when i'm looking at the runways queues i'm just going through the series until i can't go anymore | |