| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-29 | |||
| 14:11:39 | Spazmotic | something like that | |
| 14:12:38 | Spazmotic | Any chance if some gracious core gets some free cycle they could check out this review? I'm heading to Korea in like 5 days and don't want to let it sit for 2 weeks :) https://review.openstack.org/#/c/533168/ | |
| 14:13:30 | andreykurilin | so actually I do not know the "use-case". I was asked about the actual support and it looks like I found the answers. thanks mriedem and Spazmotic | |
| 14:14:18 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM: test if tempest-full is triggered or not https://review.openstack.org/537936 | |
| 14:14:56 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM: test if tempest-full is triggered or not https://review.openstack.org/537936 | |
| 14:16:20 | openstackgerrit | Ameed Ashour proposed openstack/nova master: change instance_system_metadata column type https://review.openstack.org/526900 | |
| 14:17:18 | mriedem | andreykurilin: mnestratov is the person to ask from the vz team about their status | |
| 14:17:23 | mriedem | they are the maintainers of that support | |
| 14:17:29 | mriedem | maxim nestratov | |
| 14:17:39 | andreykurilin | thanks! | |
| 14:28:30 | artom_ | stephenfin, kashyap, can I ask you guys to take a look at https://review.openstack.org/#/c/533805/2 when you get a chance? I *think* I got the libvirt XML part right, but would like expert second opinions :) | |
| 14:28:56 | artom | It's a device tagging bug :( | |
| 14:29:28 | kashyap | artom: Will try, "try" this week is bit stressful and jam-packed | |
| 14:29:40 | artom | kashyap, no worries, appreciate it | |
| 14:29:40 | kashyap | Err, /me rephrases that odd sentence | |
| 14:29:48 | kashyap | s/"try"/"try" because/ | |
| 14:31:02 | ameeda | gibi_: please check this https://review.openstack.org/#/c/526900/, I found way to get instance_system_metadata from here https://review.openstack.org/#/c/7045/5/nova/db/api.py | |
| 14:34:56 | mriedem | artom: how latent is that? not a regression in queens right? | |
| 14:35:36 | artom | mriedem, the PFs not being tagged thing? | |
| 14:35:43 | artom | mriedem, it was reported to us in Newton | |
| 14:35:49 | mriedem | artom: ok | |
| 14:36:00 | mriedem | just weighing relative severity | |
| 14:36:04 | mriedem | *urgency | |
| 14:36:24 | artom | mriedem, I don't think it was ever working | |
| 14:36:29 | artom | Based on the code | |
| 14:37:01 | mriedem | was that a separate bp from tagged attach? | |
| 14:37:03 | mriedem | must have been | |
| 14:37:34 | artom | mriedem, it was the original device tagging | |
| 14:37:38 | mriedem | oh | |
| 14:37:52 | artom | Well | |
| 14:37:56 | mriedem | i thought that was just ports and volumes? | |
| 14:38:04 | artom | I don't think we ever explicitly decided what to do about PFs | |
| 14:38:15 | mriedem | https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/sriov-pf-passthrough-neutron-port-vlan.html | |
| 14:38:17 | artom | But since a PF can be a neutron port, they're implicitly taggable? | |
| 14:38:20 | mriedem | ^ is what i'm thinking of | |
| 14:38:34 | artom | That's vlans, slightly different | |
| 14:38:47 | artom | But... I don't think those are working either, btw | |
| 14:38:53 | mriedem | great! | |
| 14:38:59 | artom | vladikr had a thing up to fix it | |
| 14:39:03 | artom | And his approach never made sense to me | |
| 14:39:06 | artom | Maybe this is why | |
| 14:39:07 | mriedem | red hat QE strikes again 2 years late | |
| 14:39:34 | artom | (Speaking of QE, we found a problem with the scheduler bypass CVE fix for the fix) | |
| 14:39:42 | artom | (Barely a week later!) | |
| 14:39:50 | mriedem | the error case? | |
| 14:39:52 | mriedem | that we fixed last week? | |
| 14:40:01 | artom | mriedem, yeah, if you rebuild again with the same image it goes through | |
| 14:40:10 | artom | Because there's a new image == old image check in the API | |
| 14:40:25 | artom | I don't have an upstream bug filed yet, but here: https://bugzilla.redhat.com/show_bug.cgi?id=1539703 | |
| 14:40:26 | openstack | bugzilla.redhat.com bug 1539703 in openstack-nova "By rebuilding twice with the same "forbidden" image one can circumvent scheduler rebuild restrictions" [Unspecified,New] - Assigned to eglynn | |
| 14:41:25 | mriedem | oh b/c we didn't reset the image on failure in the scheduler | |
| 14:41:34 | artom | mriedem, https://review.openstack.org/#/c/468758/ vladikr's PF vlan thing | |
| 14:41:38 | mriedem | which is what int32bit's patch was originally doing until i talked him out of it | |
| 14:41:52 | artom | His solution was to refresh info_cache, which seems weird | |
| 14:42:02 | artom | mriedem, well, properly rolling the changes back isn't trivial | |
| 14:42:12 | mriedem | artom: yeah i know, which was my argument in the patch. | |
| 14:42:25 | mriedem | let's just revert rebuild | |
| 14:42:42 | artom | Our of the nova api entirely? 100% behind you :) | |
| 14:43:05 | mriedem | i'll add that bz to the queens rc etherpad | |
| 14:43:22 | artom | mriedem, I'll file a proper launchpad soon | |
| 14:44:20 | mriedem | ok thanks. i think this is an easy, albeit slightly ugly fix. | |
| 14:44:54 | artom | We've said that, what, 3 times now? | |
| 14:45:11 | mriedem | jianghuaw: just to confirm, basic vgpu support for xenapi is merged, correct? the remaining patches are future work for integrating with nested resource providers? | |
| 14:45:28 | mriedem | artom: but this time it's for real | |
| 14:46:27 | mriedem | melwitt: some updates on the cellsv1 job in stable issues over the weekend - i finally opened a bug to track it https://bugs.launchpad.net/nova/+bug/1745838 | |
| 14:46:28 | openstack | Launchpad bug 1745838 in OpenStack Compute (nova) "legacy-tempest-dsvm-cells constantly failing on stable pike and ocata due to libvirt connection reset" [Undecided,New] | |
| 14:47:17 | mriedem | melwitt: and it gets a bit messy, but we need to merge the changes to bump the nova-functional job timeouts, but for that to help, we need to drop the openstack-tox-functional jobs from running on nova, which depends on these changes in stable https://review.openstack.org/#/q/Ia684786d1622da7af31aa4479fc883a7c65848ff | |
| 14:47:34 | mriedem | those changes in stable kept failing the cellsv1 job, so i stopped running the cellsv1 job on stable: https://review.openstack.org/#/c/538619/ | |
| 14:47:45 | jianghuaw | mriedem, yes for basic vgpu support. | |
| 14:48:02 | mriedem | jianghuaw: thanks | |
| 14:51:02 | bauzas | mriedem: jianghuaw: I'm working on a matrix patch that'll add the vgpu support | |
| 14:51:18 | bauzas | mriedem: jianghuaw: I'll CC you the patch once I'm done | |
| 14:51:25 | jianghuaw | bauzas, thanks. | |
| 14:51:45 | bauzas | I also have in my pipe a possible functional test for testing server actions with VGPUs | |
| 14:52:00 | bauzas | but it requires me some fixture investigation | |
| 14:52:25 | jianghuaw | bauzas, I think display head is not in queens' plan. right? Although I have a patch for that. | |
| 14:52:30 | jianghuaw | https://review.openstack.org/#/c/523342 | |
| 14:52:44 | bauzas | jianghuaw: Queens is done now | |
| 14:52:57 | bauzas | for features I mean | |
| 14:53:19 | sauloaugusto | Is there any channel for mova upgrade support ? | |
| 14:53:39 | jianghuaw | I see. the freeze-date has passed. | |
| 14:54:16 | jianghuaw | bauzas, I don't expect that can be merged:-) | |
| 14:54:40 | mriedem | melwitt: and at this point, ironically the nova-functional patches on stable are failing b/c of the openstack-tox-functional job timeouts, which we're trying to fix here, but we can't recheck anything until zuul is fixed | |
| 14:57:31 | mriedem | melwitt: oh btw, the cellsv1 job failures started around 1/18 which is around the same time as that python2.7 update in xenial repos, which was causing other gate instability related to eventlet not monkey patching os.open, | |
| 14:57:47 | mriedem | so i wondered if maybe there is some issue in libvirt-python or something in the older versions we're using on stable | |
| 15:01:24 | efried | cdent You've got me confused. | |
| 15:01:26 | jaypipes | efried, cdent: reading the vmware mail thread now.. | |
| 15:01:43 | cdent | efried: that's my goal in life | |
| 15:01:47 | efried | jaypipes cdent Note there's a followup that did go to the -dev ML. | |
| 15:02:13 | efried | cdent The part I'm confused about is: where were we ever talking about "negative traits"? | |
| 15:02:22 | cdent | we weren't | |
| 15:02:40 | jaypipes | efried: there's no such thing as a negative trait. | |
| 15:02:50 | jaypipes | efried: something either has or doesn't have a trait. | |
| 15:02:53 | cdent | we were talking about how to not consume resources that have a trait when we don't care about that trait | |
| 15:03:01 | efried | We were? | |
| 15:03:13 | jaypipes | cdent: resources don't have traits. providers have traits. | |
| 15:03:28 | cdent | jaypipes: I know, but naming it hard | |
| 15:03:41 | jaypipes | cdent: did you mean consuming resource from a provider that doesn't have a trait? | |
| 15:03:54 | cdent | jaypipes: no | |
| 15:03:57 | cdent | let me explain | |