| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-05 | |||
| 12:49:50 | sean-k-mooney | gibi: so when i was talking about macvtap i was refering to sriov in macvtap mode not the macvtap agent | |
| 12:50:31 | sean-k-mooney | gibi: so if you want to say we support sriov minium bandwith we should test both modes not just direct | |
| 12:51:02 | sean-k-mooney | i guess technically we shoudl test direct_physical to but in that case we are alloccatign the pf to the guest so it gets all the bandwith | |
| 12:51:46 | sean-k-mooney | anyway i dont want to block the patch on this point but currently it looks like you have only been looking a sriov in direct mode | |
| 12:55:31 | sean-k-mooney | for vnic_type=direct_physical we shoudl reserve the remaing bandwtih inventory for the pf as no other instances can use it in addtion to the normal allocation | |
| 12:56:13 | sean-k-mooney | techncially we should do that in some case for vnic_type=direct too as vnic_type=direct is allowed to give you a pf | |
| 12:56:36 | sean-k-mooney | direct_pysical was just intoduced to froce the alloction of a pf | |
| 12:58:55 | gibi | sean-k-mooney: regarding macvtap, if this is done by the sriov agent then I can create an extra functional test in nova to see if the nova side works | |
| 12:59:26 | sean-k-mooney | yep its done basically identically to direct jsut the vnic_type will be macvtap | |
| 12:59:32 | gibi | sean-k-mooney: yes | |
| 12:59:58 | gibi | sean-k-mooney: I will add a functional test for it in a separate patch | |
| 13:00:11 | sean-k-mooney | i basically jsut want to confrim that you dont have a hardcoded check for direct somewhere | |
| 13:00:18 | gibi | sean-k-mooney: regarding allocating a full pf for vnic_type=direct. When does that happen? | |
| 13:00:18 | sean-k-mooney | cool | |
| 13:00:37 | sean-k-mooney | it happens if the pf does not have any vfs | |
| 13:01:04 | sean-k-mooney | of if the admin whitelist pf and never allocates vfs then vnic_type=direct is allowed to used them | |
| 13:01:20 | sean-k-mooney | it was how you did pf passthough before we added direct_physical | |
| 13:01:54 | sean-k-mooney | i can double check if we prevented that when we added direct_physical but i doubt it as it would have been a breaking api change | |
| 13:02:20 | gibi | sean-k-mooney: OK. in this case the first boot will get the whole PF, and the second such boot will fail the pci claim as there is no pci device left | |
| 13:02:29 | sean-k-mooney | yep | |
| 13:03:06 | sean-k-mooney | so it wont break anything but it would be nice to tell placment that the rest of the inventory is reserved/unsuable | |
| 13:03:10 | gibi | sean-k-mooney: so the problem is that placement doesn't track PF inventory to signal that the PF is consumed | |
| 13:03:22 | sean-k-mooney | basically yes | |
| 13:03:46 | sean-k-mooney | ideally we would be asing for two things. 1 pf/vf resouce + x bandwith | |
| 13:04:21 | sean-k-mooney | since we dont track PFs/VFs in placment yet we only ask for the bandwith | |
| 13:04:25 | gibi | sean-k-mooney: OK. as far as I understand the admin needs to configur such PF specially (whitelsit the PF but not the VFs) so we can also ask the admin not to configure bandwidth for that PF as that PF will be consumed in a single piece | |
| 13:04:35 | sean-k-mooney | so this will get fix in train hopefully | |
| 13:05:24 | sean-k-mooney | ya they have to expclity whitelist the pf and that would be resonable intally at least | |
| 13:05:28 | gibi | sean-k-mooney: It will be fun moving the VF inventory to placement | |
| 13:05:45 | gibi | sean-k-mooney: OK then we will handle this case in the documentation for Stein | |
| 13:05:57 | sean-k-mooney | the downside is we wont be able to sue the min bandwith request to select pf with at least X bandwith | |
| 13:05:58 | artom | ~o~ | |
| 13:06:24 | sean-k-mooney | e.g. ask for a 10G pf vs a 1G or 40G or 100G pf | |
| 13:06:52 | sean-k-mooney | gibi: and yes moving vfs/pfs to placement will be "fun" | |
| 13:07:34 | gibi | sean-k-mooney: yeah in a mixed environment it will be a limitation | |
| 13:07:55 | sean-k-mooney | its not somthing they could do before so i think its fine | |
| 13:08:12 | gibi | yeah I feel the same | |
| 13:08:13 | sean-k-mooney | it would just be a nice bonus if we could enable that usecase in the future | |
| 13:08:43 | sean-k-mooney | but to do that we need to get a few other things in place | |
| 13:08:57 | mdbooth | lyarwood: You there? Still looking at your cinder tempest failure. | |
| 13:09:12 | mdbooth | It's pretty weird. Have you had any insight? | |
| 13:09:20 | gibi | sean-k-mooney: totally agree | |
| 13:10:58 | sean-k-mooney | anyway i responded to your replys on patchset 39 and im now going through patchset 40 but honestly i think future change can likely be done in followup patches as part fo train. | |
| 13:13:23 | gibi | sean-k-mooney: and now I've responded in your responses in PS 39 :) | |
| 13:19:21 | lyarwood | mdbooth: no, are you looking at the latest failures? | |
| 13:19:30 | lyarwood | mdbooth: I was waiting for CI to report back before taking another look | |
| 13:20:48 | mdbooth | lyarwood: I've been looking into the failures from yesterday or the day before? | |
| 13:21:13 | mdbooth | I'm currently suspecting a cinder race, tbh. | |
| 13:21:21 | mdbooth | Rather than a tempest race, that is. | |
| 13:23:02 | lyarwood | mdbooth: ack, I updated both changes this morning and they appear to be failing in the check queue. Once they report back I'll take a look to see if it's the same issue. | |
| 13:26:30 | mdbooth | lyarwood: I'll have a look at the new ones. I know what I'm looking for, now. | |
| 13:27:52 | mdbooth | lyarwood: In the one I've been looking into, we can see in both the tempest and c-api logs that cinder returns a 404 for the volume, then fails to delete the type because it still has a volume. | |
| 13:28:54 | mdbooth | I couldn't see any other volume in the logs, so my guess is that the cinder REST api is returning a 404 before updating whatever triggers the failure to delete the type. | |
| 13:29:11 | sean-k-mooney | gibi: oh i didnt know rodolfo had revied the minium bandwith work for ovs. it was merged in the past and then reverted as we found edgecase that did not work. i guess he has figured out how to work aroudn them good to know | |
| 13:29:27 | mdbooth | We can see in the c-vol logs that the volume deletion actually completes *after* the type deletion starts, so c-api is returning a 404 *before* the deletion completes. | |
| 13:29:32 | bauzas | gibi: ack, will review it later | |
| 13:34:45 | gibi | sean-k-mooney: yeah it is good that rodolfo managed to do that | |
| 13:34:47 | gibi | bauzas: thanks | |
| 13:35:51 | sean-k-mooney | it looks like tunneled netowrk support is still pendign but that was one of the things that did not work last time that ended up with the feature beign reverted | |
| 13:36:50 | sean-k-mooney | anyway having it work for flat and vlan networks i still a good step forward | |
| 13:38:02 | openstackgerrit | Chris Dent proposed openstack/nova master: Correct lower-constraints.txt and the related tox job https://review.openstack.org/622972 | |
| 13:40:40 | mdbooth | lyarwood: It has failed again. Investigating. | |
| 13:43:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Use Selection object to fill request group mapping https://review.openstack.org/638711 | |
| 13:43:56 | lyarwood | mdbooth: ack thanks | |
| 13:47:41 | mdbooth | It seems to be the py3 version which fails | |
| 14:08:37 | cdent | mriedem: the openstack-dev archives are still there, but not longer reachable by the usual paths: http://lists.openstack.org/pipermail/openstack-dev/ | |
| 14:10:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Handle templated cell mappings in nova-status https://review.openstack.org/641021 | |
| 14:10:03 | mriedem | lyarwood: try throwing that as a dependency in your tripleo change ^; dansmith fyi ^ | |
| 14:10:11 | mriedem | cdent: google failed me | |
| 14:10:28 | cdent | aye, it often does | |
| 14:13:26 | lyarwood | mriedem: ack thanks | |
| 14:18:20 | yonglihe | mriedem: what can i do for https://review.openstack.org/#/c/621476/39 | |
| 14:27:04 | dansmith | mriedem: ah, dangit | |
| 14:27:26 | openstackgerrit | Tim Rozet proposed openstack/nova stable/rocky: Fixes race condition with privsep utime https://review.openstack.org/641023 | |
| 14:29:22 | HD|Laptop | hey | |
| 14:29:42 | HD|Laptop | yesterday I asked if it was possible for nova to use cinder as backing storage for images/instances... now I had an idea | |
| 14:29:58 | HD|Laptop | can I just go ahead and mount /var/lib/nova/instances as a NFS directory? | |
| 14:30:08 | HD|Laptop | that would serve the same purpose | |
| 14:30:45 | HD|Laptop | even better would be if I could share instances/_base, but I guess that this could lead to locking issues if e.g. two compute nodes try to convert the same vmdk image to qcow2? | |
| 14:30:58 | openstackgerrit | Merged openstack/nova master: libvirt: Omit needless check on 'CONF.serial_console' https://review.openstack.org/637578 | |
| 14:39:10 | mriedem | HD|Laptop: yes you can put the instances_path config on shared storage, many people do | |
| 14:39:15 | mriedem | note that has it's own perils, like https://review.openstack.org/641023 | |
| 14:39:41 | mriedem | and https://review.openstack.org/#/c/633042/ | |
| 14:40:07 | mriedem | https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.ensure_libvirt_rbd_instance_dir_cleanup | |
| 14:40:55 | efried | mriedem: Review the "stop using PlacementDirect" changes with whitespace ignores on in gerrit | |
| 14:41:01 | efried | mriedem, cdent, sean-k-mooney: but let me rebase it first... | |
| 14:41:20 | mriedem | what if i don't want to? | |
| 14:41:59 | efried | mriedem: Then it's a bigger review that will make you sad | |
| 14:42:15 | efried | oh, what if you don't want to wait until I've rebased? Sure, then you can +2 it now, I don't mind. | |
| 14:42:28 | mriedem | strike 2 | |
| 14:45:47 | openstackgerrit | Eric Fried proposed openstack/nova master: Stop using PlacementDirect https://review.openstack.org/640887 | |
| 14:45:55 | efried | cdent, mriedem, sean-k-mooney: ^ | |
| 14:46:06 | cdent | one moment please caller | |
| 14:46:23 | HD|Laptop | mriedem: thanks. I'll just give every instance its own nfs base directory then, that should keep me safe from that shit | |
| 14:46:56 | openstackgerrit | Eric Fried proposed openstack/nova master: Stop using PlacementDirect https://review.openstack.org/640887 | |
| 14:47:09 | efried | ^ fix whitespace | |
| 14:48:37 | efried | cdent, sean-k-mooney: for a change, the 1..3 diff is actually empty, because the patch removes the whole class that was conflicting. | |
| 14:49:41 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360 | |
| 14:49:41 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543 | |
| 14:49:51 | gibi | bauzas: I've fixed up your comments ^^ | |